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I.  INTRODUCTION 


The  purpose  of  this  volume  is  to  present  the  results  of  our 
efforts  related  to  Task  2,  (Part  II)  of  our  project  task  plan.  This 
task  was  designed  to  enable  our  project  team  to  develop  an 
understanding  of  the  Navy's  existing  and  developing  ADP  internal 
controls  and  the  current  practices  of  the  Naval  Audit  Service.  This 
knowledge  was  needed  to  guide  our  research  efforts  and  provide  a  basis 
from  which  recommendations  to  improve  the  internal  control  environment 
in  the  Navy  could  be  made. 

This  chapter  provides  a  concise  explanation  of  this  volume's 
contents  and  our  objective  in  reviewing  each  research  area.  The 
remainder  of  this  introduction  discusses  each  chapter  and  the 
appendices  contained  in  this  volume  of  our  report.  The  discussion  is 
divided  into  the  following: 

.  Naval  Audit  Service 

.  NAVDAC  and  the  System  Development  Process 

.  The  NARDAC  Operating  Environment 

.  System  Surveys 

.  System  Descriptions  (Appendices  A  &  B) 

.  Observations  and  Conclusions 


Impact  of  Task  2  on  Future  Efforts. 


1. 


NAVAL  AUDIT  SERVICE 


In  conducting  our  research  it  was  important  to  understand  the 
organization  that  will  ultimately  use  the  results  of  our  research 
efforts.  This  knowledge  was  necessary  to  develop  recommendations 
tailored  to  the  needs  of  the  Navy  and  which  are  realistic  within  the 
Navy's  operating  environment.  We  obtained  information  on  the  Audit 
Service,  its  organization  and  activities,  met  with  various  members  of 
the  Audit  Service  and  reviewed  pertinent  documentation.  The  results 
of  our  efforts  are  presented  in  Chapter  II  of  this  volume  of  our  report. 


2.  NAVDAC  AND  THE  ADP  SYSTEM  DEVELOPMENT  PROCESS 


Another  area  of  understanding  which  was  required  to  conduct  our 
research  was  knowledge  concerning  the  Navy's  System  Development 
process.  Our  objective  was  to  gain  insight  into  the  system  development 
guidelines,  practices  and  procedures  followed  in  the  Navy.  In  order 
to  develop  this  knowledge  we  met  with  various  members  of  the  Naval 
Data  Automation  Command  (NAVDAC),  reviewed  pertinent  documentation  and 
developed  a  chronology  of  the  AIS  Development  and  Approval  process 
within  the  Navy.  The  information  we  obtained  in  this  regard  is 
presented  in  Chapter  III  of  this  volume. 

3.  The  NARDAC  OPERATING  ENVIRONMENT 


Controls  which  operate  in  computer  centers  are  needed  to 
complement  other  internal  controls  related  to  individual  applications 
as  well  as  controls  over  the  system  development  process.  The  NARDAC 
organization  was  selected  as  representative  of  the  Navy's  ADP  operating 
environment.  Our  purpose  was  to  understand  the  policy,  procedures  and 
organization  used  in  the  Navy  to  control  data  processing  center 
operations.  Our  intention  was  not  to  review  NARDAC  operations  in 


detail,  but  to  understand  the  organizational  structure,  security 
environment  and  other  internal  controls  related  to  the  NAftDAC  operating 
environment.  The  results  of  our  efforts  are  presented  in  Chapter  IV 
of  this  volume. 

4.  SYSTEM  SURVEYS 

Finally,  we  were  interested  in  identifying  the  types  of  advanced 
systems  the  Navy  is  developing.  Since  no  non-tactical  distributed 
systems  were  operating  in  the  Navy  when  our  project  began,  we  conducted 
a  survey  of  systems  currently  under  development.  The  objective  of 
this  task  was  to  identify  systems  under  development  which  had 
characteristics  that  were  compatible  with  our  analysis  of  advanced 
systems.  Chapter  V  of  this  volume  presents  the  results  of  our  survey 
and  briefly  discusses  the  systems  selected  for  further  review. 
Appendix  C  of  this  volume  contains  the  results  of  our  survey  of 
individual  systems  considered  for  review. 

5.  SYSTEM  DESCRIPTIONS 

After  completing  our  system  surveys  we  selected  IDA/FMS  and  PASS 
Phase  II/SDS  for  more  in-depth  reviews.  Our  objective  was  to  understand 
the  control  features  of  these  systems  and  to  document  the  flow  of  data 
through  these  two  systems.  This  system  knowledge  gave  our  project 
team  a  sound  basis  for  evaluating  the  types  of  controls  which  would 
be  most  effective  in  the  application  systems  the  Navy  was  developing. 
We  met  with  members  of  design  agencies,  project  management  personnel, 
and  reviewed  system  documentation  in  developing  our  understanding  of 
these  systems.  Appendices  A  and  B  present  the  results  of  our  review 
of  the  IDA/FMS  and  PASS  Phase  II/SDS  systems. 


6.  OBSERVATIONS  AND  CONCLUSIONS 

Chapter  VI  of  this  volume  presents  a  discussion  of  key 
observations  we  have  made  during  the  conduct  of  this  phase  of  our 
project.  It  is  designed  to  present  a  summarization  of  ideas  relative 
to  the  Navy’s  ADP  environment  and  discusses  items  which  impact  the 
internal  control  environment  in  the  Navy. 

7.  IMPACT  OF  TASK  2  ON  FUTURE  EFFORTS 


Our  project  efforts  have  reconfirmed  our  view  that  the  EDP 
environment  is  dynamic  and  rapidly  changing.  This  project  is  properly 
timed  and  provides  the  Navy  with  the  opportunity  to  devise  ways  to 
cope  with  the  new  EDP  environment  in  a  positive  manner. 

Our  future  research  efforts  will  focus  on  developing  technology, 
not  specific  Navy  applications  currently  under  development.  Advanced 
EDP  technology  will  be  emphasized  in  our  task  plan  as  follows: 

.  General  EDP  controls  (Task  3) 

.  Auditor's  Approach  and  Application  Internal  Controls  (Task 
4) 


Auditing  Techniques  (Task  5) 


II.  NAVAL  AUDIT  SERVICE 


This  Chapter  summarizes  the  background  information  we  obtained 
on  the  Naval  Audit  Service,  its  organization,  activities  and  general 
audit  policies.  Our  objective  in  obtaining  this  information  was  to 
develop  an  understanding  of  the  organization  that  will  use  the  results 
of  our  research  effort.  This  knowledge  includes  information  concerning 
current  guidance,  policy,  procedures  and  practices.  Our  discussion  is 
divided  into  the  following  sections: 

.  Organization 

.  Guidance  for  Auditing  in  the  Navy 

.  Computer  Audit  Practices. 

A  discussion  of  each  topic  is  presented  in  the  remainder  of  the 
Chapter. 

1.  ORGANIZATION 

The  Naval  Audit  Service  is  the  internal  audit  organization  of 
the  Navy,  it  is  headed  by  the  Auditor  General  of  the  Navy  who  is  a 
member  of  the  military  and  serves  collaterally  as  the  Director  of  the 
Naval  Audit  Service.  The  Auditor  General  of  the  Navy  reports  to  the 
Under  Secretary  of  the  Navy.  This  reporting  relationship  is  clear 
recognition  of  the  importance  of  internal  audit  within  the  Navy  and 
provides  the  organizational  independence  required  for  effective 
auditing.  The  Audit  Service  is  headquartered  in  Falls  Church,  Virginia 


and  the  operating  elements  of  the  organization  are  located  in  four 
regional  offices:  Northeast  region,  Camden,  New  Jersey;  Capital 
region;  located  with  Headquarters  in  Falls  Church,  Virginia;  Southeast 
region,  Virginia  Beach,  Virginia;  and  the  Western  region,  San  Diego, 
California.  An  organizational  chart  of  the  Naval  Audit  Service  is 
presented  in  Exhibit  II-l. 

The  Naval  Audit  Service's  responsibilities  can  be  summarized 
briefly  as  follows: 

Perform  independent  evaluations  of  programs,  activities, 
systems,  procedures  and  other  operations  involving  the 
expenditure  of  funds,  utilization  of  resources,  or 
accomplishment  of  management  objectives. 

The  purpose  of  the  Naval  Audit  Service  is  to  provide  service  to 
management  at  all  levels  through  the  objective  performance  of 
independent  evaluations  to  determine  the  adequacy  and  effectiveness 
of  practices,  procedures  and  controls.  This  objective  is  accomplished 
by  presenting  the  results  of  audits,  making  constructive 
recommendations  and  providing  consultation  with  management  to  assist 
in  the  formulation  of  action  plans. 

The  thrust  of  the  Naval  Audit  Service's  mission  is  somewhat 
unique.  There  are  internal  control  and  compliance  with  regulation 
responsibilities.  However,  there  is  also  a  substantial  emphasis  on 
management  efficiency  and  monetary  conservation.  These 
responsibilities  are  certainly  worthy  of  emphasis,  but  they  add  an 
additional  dimension  to  the  Auditor's  responsibilities. 

2.  GUIDANCE  FOR  AUDITING  IN  THE  NAVY 

In  order  to  obtain  a  better  understanding  of  the  Naval  Audit 
Service,  its  mission  and  objectives,  we  obtained  various  directives, 
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reports  and  publications  concerning  the  Naval  Audit  Service.  The 
purpose  of  our  review  was  to  gain  insight  into  the  mission, 
organization,  and  general  policies  of  the  Audit  Service.  A  listing  of 
the  pertinent  documentation  we  reviewed  is  presented  in  Exhibit  II-2 
at  the  end  of  this  chapter.  We  have  familiarized  ourselves  with  the 
Naval  Audit  Handbook,  several  Naval  Audit  programs,  audit  reporting 
techniques  and  audit  management  tools.  In  the  remainder  of  this  section 
we  discuss  several  of  these  documents. 

( 1 )  Naval  Audit  Handbook 

The  Naval  Audit  Handbook  is  designed  to  publish  policy, 
procedures  and  instructions  for  the  conduct  of  audits  in  the  Navy. 
It  discusses  audit  concepts  and  purposes,  approaches  to  auditing 
and  procedural  and  administrative  matters.  The  handbook  is  well 
organized,  easy  to  understand  and  provides  the  general  guidance 
needed  by  an  audit  organization  with  as  many  distant  and  diverse 
locations  as  the  Naval  Audit  Service.  Examples  and  exhibits  are 
utilized  to  illustrate  the  concepts  of  time  reporting,  standard 
audit  report  formats,  and  the  audit  utilization  process.  This 
type  of  audit  handbook  is  a  valuable  tool  to  all  members  of  the 
Naval  Audit  Service. 

(2)  Guidelines  for  Auditinq  Computer-Based  MIS  Development 


This  manual  provides  a  description  of  ADS  systems  design. 
It  is  prefaced  with  the  statement  that  the  manual  is  a  surface 
treatment  of  a  very  detailed  and  arduous  task.  it  does  provide 
an  analysis  of  system  development  audit  considerations  and 
methods  to  apply  at  certain  points  during  such  a  review.  It  also 
divides  responsibilities  for  various  audit  evaluation  steps 
between  the  auditor  and  the  computer  audit  specialist. 


The  Audit  Program  19  series  is  designed  to  segregate  into 
3  specific  programs  the  functional  programs  related  to  EDP.  EDP 
Facilities  Audits,  Systems  Development  Audits,  and  Application 
Systems  Audits  are  the  three  areas  addressed  and  each  program 
provides  comprehensive  guidance  for  auditing  these  EDP  functional 
areas.  Two  of  these  programs  are  relatively  new,  having  been 
issued  only  last  summer.  The  third  has  only  been  issued  as  a 
draft  copy. 

We  find  these  types  of  audit  tools  useful  and  believe  they  are 
valuable  to  the  members  of  the  Audit  Service.  They  form  the  foundation 
of  the  Audit  Service. 

3.  COMPUTER  AUDIT  PRACTICES 

This  section  summarizes  our  findings  regarding  computer  audit 
techniques  utilized  by  the  Naval  Audit  Service.  The  development  of 
auditing  techniques  compatible  with  advanced  EDP  technology  requires 
a  sound  understanding  of  present  Naval  Audit  Service  practices. 

Presently  different  audit  approaches  are  followed  in  individual 
regions.  For  example,  some  regions  are  heavily  involved  in  system 
development  audits,  others  concentrate  on  facilities  audits,  while 
still  others  spend  a  signficant  amount  of  their  resources  filling 
audit  retrieval  requests.  This  research  is  evidence  of  the  Naval  Audit 
Services  efforts  to  develop  a  common  approach  and  our  efforts  should 
assist  in  providing  a  basis  for  coordinating  approaches  between 
r eg  ions. 

Ideally,  consistent  audit  practices  and  approaches  should  be 


followed  by  each  region.  This  requirement  is  particularly  critical 
in  an  advanced  EDP  system  environment.  However,  it  is  clear  that 
computer  auditing  in  the  Navy  has  recently  received  additional 
attention.  Under  these  circumstances,  the  lack  of  consistency  is 
understandable  and  in  many  respects,  the  variety  of  practices  may  even 
prove  beneficial  in  deciding  on  a  consistent  Navy-wide  approach.  We 
feel  the  Audit  Service  recognizes  the  importance  of  consistency  and 
as  indicated  by  this  project,  is  interested  in  developing  consistent 
and  innovative  auditing  techniques  to  be  employed  by  Navy  auditors. 

We  have  been  impressed  with  the  experience  and  professionalism 
of  the  Audit  Service  personnel  we  have  met.  It  is  clear  that  the  trend 
to  more  sophisticated  EDP  systems  will  tax  the  expertise  of  the  computer 
auditors  and  the  entire  audit  staff.  Their  dedication  and  skills  will 
be  invaluable  as  the  Audit  Service  moves  into  a  new  decade  of  service 
to  the  Navy.  The  Audit  Service  will  have  to  respond  to  the  changes 
in  the  Navy's  ADP  environment  in  contining  to  meet  its  mission 
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Documents  Reviewed  Which  Pertain  to  the  Naval  Audit  Service 

1.  Department  of  the  Navy  Audit  Manual  for  Management. 

SECNAVINST  7510. 7A  dated  28  Decenber  1978  with  change  1 

2.  Naval  Audit  Handbook.  AUDGENAV  P-7520.1  dated  18  June  1979 

3.  The  Naval  Audit  Service  Should  Be  Strengthened.  Report  to  the 

Congress  by  the  Comptroller  General  of  the  United  States.  November 
11,  1977 

4.  Audit  Program  No.  19A  -  EDP  Facility  Audits.  AUDGENAVNOTE  7500 
dated  17  July  1979 

5 .  Audit  Program  No.  19B  -  EDP  Systems  Development 
Audits.  NAVAUDSVCNOTE  7500  dated  21  February  1979 

6.  Audit  Program  No.  19C  Application  Systems  Audits.  Draft  Copy 

7 .  A  Systems  Audit  of  the  Pay  and  Personnel  Administrative  Support 
System/Source  Data  System  (PASS/SDS)  at  Chief  of  Naval  Operations 
(QP-01)  Washington,  D.C.  Naval  Audit  Service,  Audit  Report  D  30079 
dated  1  August  1979 

8 .  Navy  Regional  Data  Automation  Center,  San  Francisco,  Alameda, 
California  (including  Naval  Data  Automation  Facility,  Lemoore , 
California) .  Naval  Audit  Service,  Audit  Report  A10078  dated 

5  June  1979. 

9 .  Navy  Finance  Center,  Cleveland,  Ohio  Allottment  Payments  System. 
Naval  Audit  Service,  Audit  Report  dated  12  April  1979 

10 .  Automatic  Data  Processing  at  Headquarters  Marine  Corps  ( HQMC ) . 

Naval  Audit  Service,  Audit  Report  C35529  dated  12  September  1979 

11 .  Financial  and  Supply  Management  Training  Course;  Navy  Comptroller 
Manual  Text.  Navy  School  of  Health  Sciences,  Bethesda,  MD  May,  197 

12.  Internal  Audit  Reports.  NAVAUDSVCINST  7520.8  dated  1  October 
1976 

13.  Guidelines  for  Auditing  Computer  -  Based  MIS  Development.  Naval 
Audit  Service. 

14.  Computerized  Auditing  in  the  Naval  Audit  Service.  Naval  Audit 
Service . 
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EDP  Systems  Audits  as  of  11/07/79.  Naval  Audit  Service,  Computer 
Listing  dated  11/8/78 

Annual  Audit  Plan.  Naval  Audit  Service,  Computer  Listing  dated 
11/20/79 


III.  NAVDAC  AND  THE  ADP  SYSTEM  DEVELOPMENT  PROCESS 


This  chapter  discusses  the  Navy's  Data  Automation  Command  (NAVDAC) 
and  internal  controls  related  to  the  Navy  System  Development  Process. 
One  of  our  initial  project  tasks  was  designed  to  enable  the  project 
team  to  become  familiar  with  the  Navy  system  of  internal  controls 
related  to  distributed  systems.  Our  preliminary  efforts  revealed  that 
presently  there  are  no  major  non-tactical  distributed  systems 
operating  in  the  Navy.  We  believe  this  situation  provides  the 
opportunity  to  emphasize  internal  controls  to  system  designers  and 
management  in  new  systems  development  efforts  at  the  optimum  point  in 
time.  By  addressing  the  question  of  internal  controls  in  distributed 
processing  systems  now,  the  Navy  will  be  able  to  consider  available 
internal  controls  in  the  system  design  stage  and  thus  reduce  or 
eliminate  the  need  for  system  modifications  and  retrofits. 

This  chapter  of  our  report  presents  a  summary  of  our  activities 
associated  with  our  review  of  the  Navy's  present  system  development 
process.  Our  objective  was  to  develop  an  understanding  of  the  practices 
and  procedures  used  in  the  Navy  to  control  the  system  development 
process.  In  order  to  facilitate  our  discussion,  we  have  divided  this 
chapter  into  the  following  topics: 

.  NAVDAC 

.  Navy  System  Development  Process  . 
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NAVAL  DATA  AUTOMATION  COMMAND  ( NAVDAC ) 


The  Naval  Data  Automation  Command  was  established  on  January  1, 
1977  as  an  echelon-two  shore  activity  under  command  of  the  Chief  of 
Naval  Operations,  and  sponsored  by  the  Director,  Command  and  Control, 
and  Communications  Programs.  Its  creation  came  about  as  a  result  of 
the  recommendations  of  the  Navy  ADP  Reorganization  Implementation 
Study  Group.  In  addition  to  the  Headquarters  Staff,  the  Naval  Data 
Automation  Command  operates  seven  Navy  Regional  Data  Automation 
Centers,  the  Department  of  Defense  Computer  Institute  and  the  Automatic 
Data  Processing  Selection  Office. 

The  overall  mission  of  the  Naval  Data  Automation  Command  is  to 
administer  and  coordinate  the  Navy's  Non-tactical  ADP  program.  This 
responsibility  includes  collaboration  on  ADP  matters  with  all  ADP 
claimants;  development  of  policy  and  procedures;  approval  of  systems 
development;  acquisition/utilization  of  ADP  equipment  and  service 
contracts;  sponsoring  of  ADP  technology;  and  career  development  and 
training  of  ADP  personnel. 

Specific  functions  of  NAVDAC  include; 

.  Provide  staff  support  to  the  Navy's  Senior  ADP  Policy 
Official  (Assistant  Secretary  of  the  Navy  (Financial 
Management)),  the  Chief  of  Naval  Operations  and  the  Director, 
Department  of  the  Navy  Automatic  Data  Processing  Management. 
These  organizational  relationships  are  illustrated  in 
Exhibit  III-l. 

.  Develop  Navy  ADP  policies,  goals,  and  objectives 

.  Manage,  control,  and  direct  ADP  field  activities  assigned 
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.  Provide  guidance  for  the  review  of  Navy  ADP  programs  and 
budgets 

.  Review  and/or  approve  automated  data  system  plans  and 
procurements.  Review  and  approval  is  accomplished  at 
differing  organizational  levels  dependent  on  the  dollar 
value  of  the  system 

.  Coordinate  ADP  systems  for  standardization  and  to  minimize 
duplication 

.  Participate  in  the  coordination  of  career  development  and 
training 

.  Prepare  Navy  ADP  technical  standards. 

The  mission  does  not  include  responsibility  for  Marine  Corps  ADP 
systems. 

A  chart  depicting  the  NAVDAC  organization  is  included  as 
Exhibit  III-2.  Our  initial  contact  with  the  Naval  Data  Automation 
Command  was  with  the  Director,  Systems  Evaluation,  and  key  members  of 
his  staff.  The  Director,  Systems  Evaluation  provides  staff  support  in 
the  review  and  evaluation  of  the  technical,  operational  and  economic 
aspects  of  all  plans  and  presents  these  plans  and  proposals  to 
appropriate  approval  authorities.  The  Director  is  responsible  for 
life  cycle  management  planning  and  evaluation  of  Navy  automated 
information  systems  and  insures  that  projects  are  in  compliance  with 
other  policies,  plans  and  standards. 

As  part  of  our  initial  contact  with  the  Naval  Data  Automation 
Command,  several  key  documents  were  obtained.  Exhibit  III-3  provides 
a  listing  of  these  documents.  Our  purpose  was  to  develop,  from  Navy 
ADP  policy  directives,  an  understanding  of  the  Navy  procedures  for 
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organization  of  Navai  Data 
Automation  command  Headquarters 
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EXHIBIT  111-3 


Documentation  Reviewed  Which  Pertains  to  Navy  ADP 

Systems 

1.  Naval  Data  Automation  Command  Headquarters  Organization  Manual. 
NAVDACHQINST  5430.1  dated  20  October  1978 

2 .  Department  of  the  Navy  Automatic  Data  Processing  Review  and 
Evaluation  Program.  OPNAVINST  10462.14  dated  19  May  1971 

3.  Specification,  Selection  and  Acquisition  of  Automatic  Data  Pro¬ 
cessing  Equipment  (ADPE) .  SECNAVINST  5236. 1A  dated  30  April  1974 

4.  Life-cycle  Management  of  Automated  Information  Systems  Within  the 
Department  of  the  Navy.  SECNAVINST  5231. 1A  dated  20  November  1979 

5 .  Automatic  Data  Processing  Approval  Authority  and  Acquisition/Develop- 

ment  Thresholds;  delegation  of  SECNAVINST  5230.6  dated  2  November 
1979 

6.  Navy  ADP  Reorganization  Study  Implementation  Plan  Report.  Volumes 
1  and  2.  Dated  21  October  1976 

7.  Naval  Data  Automation  Command  Briefing.  Dated  14  February  1978 

8.  Department  of  the  Navy  Automatic  Data  Processing  Program  Reporting 
System  CADPPRS)  —  Resources  Accounting.  SECNAVINST  5238. 1A  dated 
15  February  1973  with  change  1 

9 .  Major  Data  Processing  and  Telecommunications  Acquisition  Plans  of 
Federal  Executive  Agencies.  Fiscal  Year  1979  -  Fiscal  Year  1984. 

Office  of  Management  and  Budget.  January,  1979 

10.  Department  of  the  Navy  Automatic  Data  Processing  Program.  SECNAVINST 
5230.4  dated  3  May  1976 

11.  Safeguarding  Personal  Information  in  Automated  Dated  Systems.  SECNAVINST 
5239.1  dated  10  December  1975  with  change  1 

12.  Federal  COBOL  Compiler  Testing  Service  (FCCTS) .  SECNAVINST  5234. 1A 
dated  27  October  1976 

13 .  Department  of  the  Navy  Guidelines  for  Non-Tactical  ADP  Planning. 
SECNAVNOTE  5230  dated  26  July  1979 

14.  Information  Processing  Standards  for  Computers  (IPSC)  Program. 

SECNAVINST  5200.28  dated  29  September  1971 


automated  information  systems  development.  Exhibit  III-5  (presented 
later  in  this  chapter)  provides  a  graphic  interpretation  of  the  Navy's 
development  and  approval  process.  This  process  is  discussed  in  greater 
detail  in  the  next  section  of  this  chapter. 

Although  NAVDAC  is  a  relatively  new  organization,  several  key 
documents  are  in  various  stages  of  development  within  the  NAVDAC 
organization.  One  of  these  documents  is  the  Naval  ADP  Security  Manual. 
This  document  is  currently  available  in  the  draft  stage  and  identifies 
key  areas  of  ADP  security,  including  a  Risk  Assessment  Evaluation 
Guide.  This  Risk  Assessment  Guide,  presently  being  conducted  by  the 
various  NARDACs,  is  an  effective  method  of  raising  security 
consciousness  among  ADP  operating  installations.  Another  significant 
effort  is  the  Naval  Data  Automatic  Command  Inspector  General's  ADP 
Inspection  Guide.  This  guide  takes  requirements  from  various 
instructions  and  publications,  including  the  GAO  Audit  Guide,  and 
integrates  them  into  a  check  list. 

2.  SYSTEM  DEVELOPMENT  PROCESS 


An  understanding  of  the  Navy's  ADP  system  development  process  is 
essential  to  this  research  effort.  To  obtain  this  understanding,  we 
reviewed  Navy  system  development  policies  and  procedures  and  held 
discussions  with  Naval  Data  Automation  Command  personnel.  Our  research 
was  directed  toward  two  areas  of  study.  First,  we  obtained  an 
understanding  of  the  Navy's  organization  for  managing  ADP.  Our  efforts 
in  this  regard  were  summarized  in  the  previous  section.  With  a 
knowledge  of  the  Navy's  ADP  organization,  we  were  then  able  to  proceed 
into  the  next  area  of  concern,  that  of  understanding  ADP  system 
development  within  the  Navy. 

Navy  ADP  system  development  and  life  cycle  management  are 
supported  by  logical  and  complex  procedures.  These  ADP  system 
development  procedures  combine  system  design  and  testing  with  the 
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acquisition  and  programming/budgeting  processes  and  approval  levels 
are  regulated  by  the  dollar  value  of  the  acquisition. 

Contained  in  the  development  procedures  are  reviews,  audits  and 
milestone  approvals  to  insure  that  there  is  a  need  for  the  system, 
that  the  appropriate  alternative  has  been  selected  and  that  the  system 
design  meets  the  standards  of  efficiency  and  effectiveness  set  for 
the  system.  These  system  development  audits  and  reviews  are 
graphically  presented  in  Exhibit  III-4.  During  these  audits  and 
reviews,  the  strength  of  internal  controls  and  the  ability  to  audit 
data  contained  in  the  system  can  be  determined.  Recommendations  to 
strengthen  internal  controls  and  auditability  can  also  be  made. 

Exhibit  III-5,  Chronology  of  Automated  Information  System  (AIS) 
Development  and  Approval  within  the  Navy,  provides  a  graphic 
interpretation  of  our  understanding  of  the  system  development  process. 
The  development  process  requires  appropriate  documentation  to  be 
prepared  during  the  various  stages  of  system  development.  There  are 
also  management  reviews  called  for  if  developmental  efforts  exceed 
projected  budget  and  time  restraints.  These  requirements  lead  to  a 
more  manageable  development  process  and  prohibit  uncontrolled  projects 
from  rambling  on.  The  development  process  is  fairly  new  but  should 
increase  the  quality  and  manageability  of  the  Navy's  system  development 
efforts. 
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AIS  Systems  Development  Reviews 


CDR:  Critical  Design  Review  -  A  formal  review  of  the  final  draft  of 

a  computer  program  may  be  conducted  on  two  or  more  programs  at 
one  time. 

FCA:  Functional  Configuration  Review-  Verifies  code  re-program 

specifications  and  notebooks. 

FQR:  Functional  Qualifications  Review  -  Validate  performance  and 

results. 

PDR:  Preliminary  Design  Review  -  A  formal  review  of  the  initial  draft 
of  a  computer  program  specification  to  assure  that  the  design 
is  in  accordance  with  system  requirements. 

RARs  Requirements  Analysis  Review  -  Review  operational,  functional, 
and  technical  requirements. 

SDR:  Systems  Design  Review  -  Review  of  system's  hardware,  software 

and  telecommunications  requirements. 

SRR:  Systems  requirements  Review  -  System's  application  software 

requirements. 


Chronology  of  Automated  information  System 


(Al 


DEVELOPMENT 

MISSION  ANALYSIS 

MILESTONE  0 

CONCEPT 

MILESTONE  1 

DEFINf 

PROCEDURES 

PROJECT  INITIATION 

APPROVAL 

DEVELOPMENT 

APPROVAL 

Major  Tasks 

•  Identify  Mission  Element 

•  Authority  is  Given  to 

•  Develop  Alternatives 

•  Decision  to  Proceed  to  • 

Function 

Accomplished 

Need 

Explore  and  Develop 

•  Designate  Project  Manager 

Definition/Design  of  an 

and  Proa 

During  Phase 

•  Validate  Need 

Alternative  Concepts 

•  Modeling  and  Simulation 

AIS  Based  on  a  Single  Concept 

are  Detal 

•  Recommend  the  Exploration 

of  Concepts 

•  Funds  Programmed  or  Budgeted  • 

Obiactiw 

of  Alternatives 

•  Demonstration  of 

Performs 

Alternatives  (Optional) 

•  Economic  Analysis 

•  Acquisition  Strategy 

•  Validate  AIS  Requirement 

•  Analyze  Requirements 

s«t  Font 

Documentation 

•  Mission  Element  Need 

•  System  Decision  Paper 

a  SyU 

Statement  (MENS) 

ISOPI 

a  SyU 

•  Project  Management  Plan 

a  Upd 

•  Acquisition  Documents 

a  Pm 

•  Security  Analysis 

a  TaM 
a  Qua 

a  Con 

GENERAL  NOTES  ACCOMPANYING  CHRONOLOGY 


(T)  NAVDAC  coordinates  AIS  approvals  for  ASSTSECNAV  <FM). 


r2  ;  Program  sponsors  are  responsible  for  validating  requirements  and  programming/budgeting  funds. 
(^T)  Approving  Authority  Coordinates  with  GSA.  Copies  of  documents  go  to  NAVDAC. 

^  Approval  authorities  are  to  provide  for  the  periodic  audit  of  AIS  development. 


The  Automated  Data  System  Plan  (ADS  Plan)  is  similiar  to  the  SDP  and  has  been  used  for  development  occurring 
before  the  requirement  for  an  SDP. 

The  design  of  the  system  should  facilitate  a  functional  and  a  technical  audit  of  the  AIS. 
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System  (AIS)  Development  and  Approval  within  the  Navy 
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MILESTONE  II 
APPROVAL 


SYSTEM 

DEVELOPMENT 


MILESTONE  III 
APPROVAL 


DEPLOYMENT/OPERATION 


I  to  • 

•  of  an 

pe  Concept 
I  or  Budgeted  « 


Functional  Requirements 
and  Processes  to  be  Automated 
are  Detailed 
Objectives,  in  Terms  of 
Performance  Measurements. 

Set  Forth 


Decision  to  Proceed 
to  System  Development 


>  Develop.  Integrate.  Test 
and  Evaluate  the  Al$ 
Computer  Programs  and 
Data  Bases  Developed 
Functional  Configuration 
Audit 

Physical  Configuration 
Audit 

Product  Verification  Review 
Verify  that  System  Satisfies 
Design  and  Functional 
Requirements 
Site  Readiness  Review 


Decision  to  Daploy  and 
Operate  tha  System  at 
Operational  Sites 


•  Acquire.  Daploy  and 
Operate  System 

•  Maintain  and  Modify 
System 

•  Performance  Education 


i  System  Design 
•  System  Specs 
i  Updated  SOP 
i  Procurement 
1  Test  and  Eval 
Quality  Assurance 
Configuration  Mgmt. 


\  Plans 


Programs  and  Documentation 
Maintenance  Manuals 
User  Manuals 
Operation  Manuals 
Updated  SDP 
Test  Reports 
Solicitation  Document 


development  occurring 


IV.  THE  NARDAC  OPERATING  ENVIRONMENT 


This  chapter  describes  the  data  processing  operations  of  Navy 
Regional  Data  Automation  Centers  (NARDACs) .  Our  visits  to  NARDACS 
were  designed  to  identify  ADP  internal  controls  within  the  Navy's  ADP 
operating  environment.  Throughout  Task  2  we  emphasized  the  internal 
control  features  of  the  Navy's  data  processing  environment  to  guide 
and  support  our  internal  controls  research. 

The  NARDAC  concept  is  relatively  new  and  is  being  executed  over 
a  period  of  time.  We  have  discussed  this  concept  with  members  of  the 
Navy's  data  processing  community  and  have  included  it  in  this 
description.  Similarly,  the  NARDAC/user  relationship  is  being 
redefined.  There  are  about  350  Navy  data  processing  centers,  including 
seven  NARDACs  in  the  Navy.  We  selected  two  NARDACs  at  which  to  gain 
an  understanding  of  the  Navy's  data  processing  environment.  The 
NARDACs,  located  at  Washington,  D.C.  and  Pensacola,  Florida,  were 
selected  for  the  following  reasons: 

.  NARDACs  are  important  Navy  data  processing  centers  and  the 
Navy  is  moving  to  increase  their  importance 

.  NARDACs  provide  a  concentrated  look  at  a  variety  of  Navy 
data  processing  configurations  and  a  variety  of  applications 

.  NARDACs  serve  multiple  customers 


The  two  distributed  systems  we  reviewed,  IDA/FMS  and  PASS 
Phase  II  (SOS),  will  have  data  processed  at  NARDACs 


.  NARDAC  Washington,  D.C.  serves  as  a  data  processor  for 

numerous  Navy  high  level  offices  and  commands.  Therefore, 
many  distributed  systems  which  will  process  and  distribute 
information  up  the  chain  of  command  or  use  high  level  data 
bases  may  have  processing  done  at  NARDAC  Washington 

.  IDA/FMS  is  operational  at  NARDAC  Pensacola.  PASS  will  also 
be  run  at  NARDAC  Pensacola. 

We  have  divided  our  discussion  of  the  Navy  data  processing  environment 
into  the  following  sections: 

.  An  Overview  of  the  Navy's  Data  Processing  Environment 

.  Organization  of  the  NARDAC  and  the  Resulting  Internal 

Controls 

.  Customer  Relations 

.  Hardware 

.  Internal  Controls 

We  have  met  with  personnel  at  the  Navy  Regional  Data  Automation 
Centers  located  at  Pensacola  and  Washington,  D.C.  Additional 
information  was  obtained  from  members  of  the  Naval  Data  Automation 
Command  and  through  the  review  of  pertinent  documentation.  The 
discussion  of  internal  controls  is  based  on  this  information,  not  on 
audit  or  inspection  procedures. 
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1.  AN  OVERVIEW  OF  THE  NAVY'S  DATA  PROCESSING  ENVIRONMENT 


In  1976,  a  Navy  ADP  Reorganization  Implementation  Study  Group 
made  various  recommendations  to  improve  the  Navy's  management  of  ADP. 
As  a  result,  the  Naval  Data  Automation  Command  (NAVDAC)  was  formed  in 
January  of  1977.  NAVDAC  is  the  manager  of  the  Navy's  ADP  efforts. 
Exhibit  I V-l  illustrates  the  command  relationships  involved  in  the 
management  of  the  Navy's  ADP  resources. 

In  order  to  provide  ADP  support,  NARDACs  were  formed.  NARDAC 
Pensacola's  mission  includes  the  following  services: 

.  Regional  non-tactical  ADP  services  to  Navy  activities 

.  Manage  and  direct  remote  facilities,  Naval  Data  Automation 
Facilities  (NAVDAFs) ,  which  provide  non-tactical  ADP 
services  in  their  areas 

.  Design,  develop  and  maintain  standard  Navy  non-tactical 
automated  data  processing  systems. 

NARDACs  have  been  located  in  areas  of  heavy  concentration  of 
Naval  activities.  There  are  currently  7  NARDACs  and  there  is  the 
possibility  that  additional  NARDACs  will  be  formed.  NARDACs  have 
utilized  existing  ADP  facilities  and  equipment.  NARDAC,  Washington, 
D.C.  was  formed  in  March  1977  from  the  resources  of  four  data  processing 
facilities.  NARDAC  Pensacola,  was  formed  in  October,  1977  with  the 
transfer  of  the  Naval  Education  and  Training  Information  Support 
Activity  (NETISA)  to  NAVDAC  and  the  additional  transfer  of  four  other 
geographically  separate  data  processing  centers.  Somewhere  between 
25  to  50  percent  of  the  Navy's  ADP  resources  are  presently  controlled 
by  NARDACs. 


In  order  to  improve  the  Navy's  ADP  services,  the  following  have 
been  standardized  among  NARDACs : 

.  Organizational  structure 

.  Mission  and  functions 

.  Military  billet  descriptions  and  civilian  position 

descriptions 

.  Operating  procedures 

.  Similiar  staffing  for  equivalent  work 

.  Civilian  position  classification 

.  Career  progression 

.  Training. 

While  all  NARDACs'  adopted  the  standard  organizational  structure, 
they  vary  in  size.  The  three  sizes  are  1,200,  317  and  190  personnel. 
NARDAC  Washington  will  have  1,200  personnel  and  will  be  the  only  NARDAC 
this  large.  NARDAC  Pensacola  will  have  317  personnel.  Current  plans 
call  for  all  positions  and  billets  to  be  authorized  within  two  years. 

Many  of  the  data  processing  facilities  which  became  NARDACs  are 
housed  in  buildings  which  were  originally  designed  for  functions  far 
different  from  those  of  a  data  processing  center.  This  has  led  to 
problems  in  the  areas  of  security,  electrical  power,  floor  arrangement 
of  equipment  and  environmental  control.  There  are  provisions  in  the 
planning  for  the  Military  Construction  Appropriation  to  build 
dedicated  data  processing  centers  or  rehabilitate  present 


NARDACs  have  been  created  to  provide  a  range  of  ADP  services  to 
meet  a  variety  of  customers'  needs.  These  services  range  from  advising 
and  planning  assistance  to  the  processing  of  data.  The  NARDAC  is  not 
now  nor  is  it  intended  to  be  the  only  type  of  data  processing  center 
in  the  Navy.  NARDACs  are  envisioned  as  being  in  competition  with  other 
data  processing  centers  for  customer  useage.  As  part  of  the  economic 
analysis  for  acquiring  new  data  processing  equipment  the  requestor 
must  examine  the  merits  of  using  a  NARDAC  for  processing.  However, 
there  is  no  requirement  that  new  applications  be  processed  at  a  NARDAC. 

2.  ORGANIZATION  OF  THE  NARDAC  AND  THE  RESULTING  INTERNAL  CONTROLS 

The  purpose  of  this  section  is  to  describe  the  standard 
organization  of  a  NARDAC.  NARDAC  Pensacola,  a  mid-sized  NARDAC,  is 
used  here  for  illustrative  purposes.  The  organization  described  here 
is  the  organization  toward  which  NARDACs  are  moving.  An  illustration 
of  this  organization  is  presented  in  Exhibit  IV-2.  This  chart  also 
shows  the  NAVDAFs  assigned  to  NARDAC  Pensacola. 

In  the  following  paragraphs,  we  briefly  describe  the  organization  and 
functions  of  the  various  departments  of  NARDAC  Pensacola. 

( 1 )  Senior  Management 


In  addition  to  the  Commanding  Officer  and  the  Executive  Officer, 
NARDACs  have  a  Technical  Director  and  a  Liaison/Planning  Officer.  The 
Technical  Director  is  responsible  for  the  technical  direction  of  the 
NARDAC  and  the  coordination  of  the  various  functions  performed  in  the 
NARDAC.  The  Liaison/Planning  Officer  serves  as  a  point  of  contact  for 
customers.  This  Officer  advises  NARDAC  management  as  to  various 
customer  requirements  and  promotes  the  NARDAC's  services  to  potential 
customers.  The  Liaison/Planning  Officer  also  determines  customer 
requirements  and  integrates  these  into  NARDAC  plans  for  the  future. 

i. 
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The  functions  of  the  Management  Support  Department  include 
administration,  financial  management,  personnel  mangement  and 
management  analysis.  This  department  has  two  divisions,  one  of  which 
performs  the  financial  management  function  while  the  other 
accomplishes  the  remaining  functions.  At  NARDAC  Pensacola  this 
department  will  have  20  people  when  fully  staffed. 


Technical  Sui 


jar  tment 


This  department  provides  ADP  technical  and  management  support  to 
other  NARDAC  departments  within  the  same  NARDAC,  other  NARDACs  and 
other  Navy  users.  Their  duties  include  the  review  and  promulgation 
of  standards,  including  those  for  training  and  documentation.  The  ADP 
Technical  Security  Staff  which  is  part  of  this  department,  provides 
system  software  for  ADP  security,  interprets  standards,  issues  policy 
and  the  security  plan.  The  System  Support  Division  is  responsible 
for  developing  systems  software  for  telecommunications  and  data  base 
management.  Configuration  planning  and  management  and  performance 
evaluation  are  the  responsibility  of  the  Planning  and  Analysis 
Division.  At  NARDAC  Pensacola,  this  department,  when  fully  staffed, 
will  have  40  people. 


Data  Processinc 
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This  department  plans,  designs  and  develops,  impl ements,  ma inta ins 
and  documents  application  programs.  The  Requirements  Analysis  and 
Design  Division  provides  initial  customer  contact  for  feasibility 
studies,  system  descriptions  and  functional  descriptions.  The  Systems 
Engineering  and  Development  Division  provides  application  programming. 
These  two  divisions  are  organized  into  teams  to  provide  maximum 
customer  service.  These  divisions  also  evaluate  the  efficiency  of 
system  and  application  programs.  There  are  sixty  eight  positions 
assigned  to  this  department. 
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The  Data  Processing  Installation  Department  controls  and  operates 
the  Data  Processing  Center  which  includes  the  automatic  data  processing 
equipment,  peripherals,  and  the  teleprocessing  network  and  equipment. 
It  provides  batch,  teleprocessing  and  remote  job  entry  data  processing 
services  to  local  and  out  of  area  customers.  It  is  the  largest 
department  of  the  NARDAC. 

The  Installation  Management  Staff  is  responsible  for  budgeting, 
training  and  risk  management  of  the  data  center,  including  overall 
security.  The  Operations  Division  is  responsible  for  operating  the 
data  processing  equipment  excluding  the  teleprocessing  equipment.  The 
Production  Control  Division  is  responsible  for  production  control, 
scheduling  and  quality  control.  Assigned  here  are  the  Systems  Managers 
for  each  of  the  processing  systems  operated  at  the  NARDAC  and  library 
functions  are  carried  out  within  this  division.  The  Acceptance 
Test/Recovery  Division  is  responsible  for  the  acceptance  testing  of 
application  programs  developed  for  customers  by  Central  Design  Agents, 
such  as  the  Fleet  Material  Support  Office  or  the  Naval  Air  Logistics 
Command,  as  well  as  those  developed  internally  by  the  NARDAC 
Programming  Support  Department.  Systems  software  is  also  tested  by 
this  group  within  the  NARDAC  environment.  NARDAC  Pensacola  is  working 
toward  the  retroactive  acceptance  testing  of  all  application  programs 
it  now  processes.  In  addition  to  acceptance  testing,  during  which  it 
analyzes  programs,  this  division  also  identifies  problem  areas  and 
applies  changes,  which  are  written  other  organizations  to  application 
programs.  This  division  is  also  responsible  for  immediate  recovery 
procedures.  Within  the  Acceptance  Test/Recovery  Division,  teams  are 
organized  to  work  with  individual  applications.  The  Teleprocessing 
Division  controls  and  operates  the  teleprocessing  equipment  and 
monitors  the  status  of  equipment  on  an  around  the  clock  basis.  In 
addition,  it  is  responsible  for  system  passwords.  In  coordination  with 
the  Production  Control  Division,  it  controls  teleprocessing  equipment. 


Within  the  Data  Processing  Department,  there  is  a  segregation  of 
the  operations,  control,  library,  acceptance  testing  and  recovery  and 
the  security  functions.  These  functions  are  organizationally 
segregated  from  other  functions  such  as  application  and  systems 
programming,  standards  development,  ADP  systems  design  and  software 
security.  The  Data  Processing  Installation  Department,  when  at  full 
strength,  will  have  184  of  the  317  NARDAC  Pensacola  positions  and 
billets. 

( 6 )  NARDAC  Washington 

The  organization  of  NARDAC  Washington  is  different  from  the 
standard  NARDAC  organization  due  to  its  larger  size.  The  data 
processing  operations  and  the  location  of  its  processing  centers  are 
the  most  significant  variables.  The  organizational  variations  of  two 
major  departments  at  NARDAC  Washington  are  outlined  below. 

The  Data  Processing  Programming  Support  Department  is  organized 
to  provide  support  to  different  types  of  applications.  These  are: 

.  Teleprocessing 

.  Financial 

.  Logistics 

.  Personnel 

The  Data  Processing  Installation  Department  is  called  a 
directorate  and  has  three  departments;  each  has  different  processing 
equipment.  The  organization  of  this  directorate  by  type  of  processing 
equipment  is: 

.  IBM  equipment  located  at  four  sites  in  Metropolitan 

Washington 
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Univac  Equipment  located  at  the  NARDAC 


.  minicomputers  at  26  sites  throughout  Washington 

These  departments  have  the  same  four  divisions  as  the  standard  NARDAC 
Organization:  Operations,  Production  Control,  Acceptance 

Test/Recovery  and  Teleprocessing.  The  IBM  Department  has  personnel 
from  the  four  divisions  at  each  of  the  four  hardware  sites.  However, 
plans  call  for  the  consolidation  of  all  IBM  equipment  at  the  NARDAC 
facility  located  in  the  Washington  Navy  Yard. 

3.  CUSTOMER  RELATIONS 

The  NARDAC  concept  is  based  on  the  creation  of  a  demand  for  its 
services.  NARDACs  are  organized  to  offer  various  levels  of  service 
to  each  user.  The  level  of  service  concept  recognizes  that  customer 
requirements  for  various  data  processing  tasks  performed  by  a  NARDAC 
vary  with  the  user's  ADP  knowledge,  resources,  and  the  type  of 
processing  to  be  accomplished.  As  the  processing  functions  for  each 
application  are  essentially  similar,  these  functions  are  spelled  out 
and  the  user  can  select  those  that  the  NARDAC  will  perform  and  those 
that  the  user  will  retain  responsibility  for.  The  level  of  service 
options  extends  from  complete  system  design,  implementation  and 
processing  to  simply  the  processing  of  data. 

The  functional  description  of  the  NARDAC  organization  indicates 
the  levels  of  service  which  are  available  and  the  level  of  service 
concept  provides  the  user  with  a  clear  understanding  of  what  type  of 
service  is  being  requested  from  the  NARDAC  and  what  responsibilities 
must  be  accepted  by  the  user.  The  NARDAC  can  support  the  user  with 
feasibility  studies,  functional  descriptions,  system  descriptions, 
programming  and/or  maintenance.  In  some  cases,  Central  Design  Agencies 
will  design  a  system  and  provide  programming  support,  then  present  the 
system  to  a  NARDAC  for  acceptance  testing.  In  other  cases,  the  NARDAC 
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will  provide  programming  support  to  a  customer  who  may  have  another 
data  processing  center  run  the  application.  These  management  and 
support  relationships  are  diagramed  in  Exhibit  IV-3.  ADP  long-range 
planning  should  be  improved  within  the  Navy  by  this  type  of  cooperative 
planning  being  entered  into  by  the  NARDAC  and  the  user.  The  NARDAC 
will  help  the  user  identify  hardware  and  software  requirements  and 
thus  facilitate  NARDAC  and  NAVDAC  planning.' 

NARDAC  customers'  work  is  funded  by  the  direct  funding  of  the 
NARDAC  through  the  Chief  of  Naval  Operations  and  the  NAVDAC  funding 
chain  or  by  reimbursement  from  the  customer.  At  NARDAC  Pensacola,  the 
FY  80  budget  calls  for  83%  of  the  funding  to  be  direct  to  the  NARDAC 
and  17%  to  be  reimbur seable  work.  The  desired  trend  is  toward  a  total 
chargeback  system  which  is  further  discussed  in  Section  5  of  this 
chapter.  Non-Navy  customers  can  be  supported  by  Inter  Service  Support 
Agreements  or  other  types  of  agreements,  however  at  this  time,  NARDAC 
Pensacola  does  not  serve  any  non-Navy  customers.  Their  user's  can  be 
classified  as  shown  in  Exhibit  IV-4. 

4.  HARDWARE 

The  purpose  of  this  section  is  to  illustrate  the  data  processing 
equipment  at  a  NARDAC.  NARDACs  do  not  possess  standardized  equipment 
as  they  were  formed  from  data  processing  centers  which  had  no  command 
relationship.  Standardization  of  equipment  has  been  accomplished  by 
the  installation  of  UNIVAC  1100/40  series  processing  equipment. 

NARDAC  Pensacola  presently  has  the  following  hardware  processing 
systems : 

.  UNIVAC  1100/44.  This  is  a  large  scale  multiprocessing  system 
with  four  central  processors  and  four  input/output 
controllers.  Immediate  access  to  approximately  10  billion 
characters  of  data  is  provided  by  a  removable  disk  subsystem 
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NARDAC  Pensacola  Customers 


Command 


Chief  of  Naval  Education 
and  Training  (CNET) 


Naval  Air  Rework 
Facility  (NARF) 

Chief  of  Naval  Material 
(CNM)/:tarf 

Naval  Air  Logistics 
Command  ( NALC ) /NARF 

Fleet  Material  Support 
Office/Naval  Air 
Station  Supply 

Various 


Purpose  of  System 

10  separate  major 
ADP  systems  including 
Integrated  Disbursing 
&  Accounting  (IDA). 
Most  are  to  support 
training 

NARF  Applications 


Maintenance  Management 
(3M) 

Aviation  Engine 
Management  System  (AEMS ) 

Stock  Point  Supply 
System  (UADPS-SP) 


Civilian/Military 
(JUMPS)  Payroll 


The  above  table  does  not  include  systems  located  at 
NARDAF s . 


Exhibit  IV -4 


Equipment 

IBM  360/65  (Being 
replaced  by  UNIVAC 
1100/44) 

UNIVAC  1100/44 
UNIVAC  1100/44 
UNIVAC  1100/44 
Burroughs  3500/4700 

Burroughs  3500/4700 
NARDAC  Penscola's 


and  a  data  base  management  system.  Communications  is 
controlled  by  front-end  processors  called 
communications/symboint  processors  (CSPs).  The  CSPs  also 
control  printers,  card  readers  and  card  punchers.  With  the 
UNIVAC  1100/40  system  NARDACs  have  the  capability  to  serve 
unrelated  users  simultaneously. 

.  Burroughs  3500/4700.  This  is  a  dual,  medium  scale  computer 
system  with  independent  processors.  Each  processor  can 
handle  multiple,  independent  jobs.  System  communications  is 
controlled  through  the  use  of  a  multi-line  controller  which 
permits  multiple,  simultaneously  operating  communications 
lines  to  input/output  channels.  The  Burroughs  hardware  gives 
NARDAC  Pensacola  the  ability  to  process  a  variety  of  business 
applications  concurrenlty  using  a  data  base  concept. 

.  IBM  360/65.  This  system  supports  the  multiple  applications 
of  the  Naval  Training  Information  System  (NAVTIS) .  It  is 
one  of  the  larger  mid-size  processors.  An  extensive  system 
of  on-line  communication  is  used  in  conjunction  with  IBM 
360/65.  Applications  run  on  this  system  are  being  phased 
over  to  the  UNIVAC.  This  conversion  process  should  be 
completed  by  August,  1980. 

NARDAC  Pensacola  operates  communications  networks  for 
teleprocessing  which  are  illustrated  in  Exhibit  IV-5.  These  networks 
extend  along  the  East  Coast,  through  the  midwest  and  to  two  sites  in 
California.  Each  processing  system  operates  an  on-line  system.  There 
is  also  an  extensive  point  to  point  tape  system  using  MOHAWK  2400 
equipment  and  there  are  currently  seventy  communications  lines  into 
the  NARDAC.  There  are  also  remote  job  entry  devices  located  in  the 
Pensacola  area.  We  have  not  described  NARDAC  Washington  equipment  due 
to  the  size  of  the  NARDAC  and  its  unique  nature. 
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nardac  Pensacola  Teleprocessing  Networks 


EXHIBIT  IV-5 
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INTERNAL  CONTROLS 


This  section  describes  the  NARDAC  internal  control  environment. 
Our  discussion  is  divided  into  two  sections:  security  and  other 
controls. 

(1)  Security 

In  this  section  we  describe  the  security  environment  of  the 
NARDACs  at  Pensacola  and  Washington,  D.C.  Although  this  section  deals 
primarily  with  physical  security,  we  also  discuss  the  draft  copy  of 
the  Navy  ADP  Security  Manual  being  written  by  NAVDAC.  Its  purpose  is 
the  establishment  of  a  Navy  program  for  the  security  of  ADP  facilities. 
This  manual  is  directed  toward  the  NARDAC  and  other  Navy  data 
processing  centers.  The  Draft  Security  Manual  addresses  the  following 
topics : 


.  ADP  Security  Training 

.  Auditor  Involvement  in  ADP  System  Development 

.  Contingency  Planning 

.  Risk  Assessment 

.  Countermeasures 

.  Assessments. 

Both  NARDACs  we  visited  are  presently  performing  a  risk  assessment 
to  determine  vulnerability  caused  by  loss  of  service  or  by  unauthorized 
access.  Detailed  procedures  for  conducting  the  risk  assessment  are 
set  forth  in  the  NAVDAC  Draft  Security  Manual.  The  risk  assessment 
process  is  a  detailed,  encompassing  procedure  which  is  staff  intensive 
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and  is  accomplished  over  a  period  of  time.  It  is  designed  to  accomplish 
the  following: 


.  Identify  and  evaluate  threats  to  ADP  systems  and  to  the  ADP 
facility 

.  Identify  and  evaluate  the  importance  of  the  ADP  system  and 
facility  resources 

.  Estimate  the  Annual  Loss  Expectancy  if  a  threat  were  realized 

.  Estimate  the  level  of  risk  to  which  classified,  sensitive 

or  mission  essential  assets  are  exposed 

.  Identify  those  threats  which  could  cause  the  greatest  harm 
and  recommend  the  most  cost  effective  way  to  reduce  or 
eliminate  the  threats. 

The  risk  assessment  looks  at  both  threats  and  vulnerabilities. 

A  threat  comes  from  a  source  outside  of  the  facility  whereas  a 
vulnerability  is  a  weakness  in  the  physical  layout,  organization, 
procedures,  hardware  or  software  of  the  data  processing  facility.  An 
example  of  a  threat  evaluation  form  is  provided  at  Exhibit  IV-6.  The 
risk  assessment  concerns  itself  with  internal  controls  as  well  as 
secur i ty. 

Both  NARDACs  we  visited  are  finding  the  risk  assessments  a  useful 
vehicle  for  assessing  security  and  internal  control.  Both  expect  to 
change  policy  and  procedures  as  a  result  of  the  risk  assessment.  Other 
security  considerations  are: 

.  Physical  Access  -  Both  NARDACs  use  electronically  coded 

badges  to  which  an  electronic  sensing  device  at  the  entrance 
to  the  Computer  room  reacts.  The  device  at  NARDAC  Washington 
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Threat  Evaluation  Form 
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is  programmed  to  take  into  account  the  time  frame  within 
which  a  person  is  entering  the  Computer  room.  A  person  on 
a  particular  shift  can  only  enter  the  Computer  room  within 
a  pre-established  time  frame.  NARDAC  Washington  also  has 
guards  at  the  entrances  to  the  building  and  alarmed  doors. 
NARDAC  Pensacola  is  working  toward  a  greater  restriction  of 
entry  into  its  facility  and  has  closed  circuit  TV  cameras 
at  unguarded  entrances  and  the  Data  Processing  Center  has 
alarmed  doors. 

Environmental  Considerations  -  3oth  NARDACs  have  air 
conditioning  systems.  NARDAC  Pensacola  has  a  second  system 
for  reserve  air  conditioning.  NARDAC  Washington  has  some 
backup  capability.  Both  data  processing  centers  have 
environmental  monitors  which  measure  temperature  and 
humidity  within  the  processing  environment. 

Electricity  -  NARDAC  Pensacola  has  backup  capability  in  the 
form  of  an  emergency  diesel  generator,  but  this  generator 
cannot  assume  the  full  operating  load  in  the  case  of  power 
interruption.  Some  of  NARDAC  Washington's  centers  have 
backup  electrical  power  and  others  do  not.  NAVDAC  plans  to 
include  uninterruptable  power  supplies  as  part  of  its  plans 
for  the  construction  of  new  Data  Processing  Centers  or  the 
rehabilitation  of  the  present  centers. 

Passwords  -  Both  NARDACs  have  passwords  and,  to  some  extent, 
utilize  user  ID  numbers  as  part  of  a  program  for  terminal 
security.  System  security  varies  with  individual 
appl ication. 

Fire  Protection  -  Both  NARDACs  have  fire  protection.  NARDAC 
Pensacola  has  an  underfloor  C02  system  in  the  data  processing 
center  and  a  sprinker  system  in  the  tape  library.  Each 
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sprinker  is  individually  activated  by  its  own  sensing 
device. 

% 

( 2)  Other  Controls 

In  this  section  we  present  other  internal  controls  operational 
at  a  NARDAC.  We  have  attempted  to  determine  when  a  procedure  is 
standard  practice  for  all  NARDACs  and  when  it  is  applicable  only  to 
the  NARDACs  we  visited.  However,  this  was  not  always  possible.  The 
following  internal  controls  can  be  expected  to  be  in  place  at  NARDAC's 
(or  are  present  at  the  NARDACs  we  visited): 

.  Acceptance  Testing  -  All  new  applications  are  production 
tested  to  determine  if  they  will  run  effectively  in  a  NARDAC 
operating  environment  before  being  accepted.  Standards  for 
acceptance  testing  will  be  published  shortly  by  NAVDAC. 
Plans  call  for  all  existing  applications  to  be  retroactively 
acceptance  tested. 

.  Computer  Resource  Utilization  -  NARDACs  are  looking  at 
applications  for  inefficient  usage  of  computer  resources. 
They  are  working  with  the  various  Central  Design  Agencies 
and  NAVDAC  to  attempt  to  optimize  the  use  of  computer 
resources  in  the  Navy. 

.  Librarian  Function  -  Tape  librarians  are  assigned  and  the 
Production  Control  Division  tries  to  schedule  a  librarian 
on  all  shifts  at  NARDAC  Pensacola.  An  automated  tape  library 
system  is  operational  at  Pensaocola,  which  controls  the 
issuing  of  tapes  for  production  runs.  This  system  also 
maintains  a  perpetual  inventory  of  tapes.  Program 
documentation  is  maintained  by  the  Acceptance  Test/Recovery 
Division.  At  NARDAC  Washington,  the  automated  IBM  scheduling 
system  checks  for  the  authority  to  use  a  tape  for  each 
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individual  job,  assures  that  the  proper  tape  is  used,  and 
lists  any  I/O  errors  on  that  tape.  This  system  also  provides 
a  tape  inventory  automatical ly. 

Testing  -  Testing  is  required  as  part  of  the  system 
development  effort  and  independently  verified  during 
acceptance  testing.  Test  results  are  provided  to  the  user, 
the  Data  Processing  Installation  Department  and  various 
NARDAC  managers.  Only  personnel  involved  in  the  testing  can 
access  the  test  files  unless  an  agreement  with  the  user 
indicates  otherwise.  NARDAC  Pensacola  plans  to  use  a  test 
bad  at  NAVDAF  Newport  for  testing  to  maintain  a  separation 
between  testing  and  local  production  runs. 

Program  Changes  -  At  NARDAC  Pensacola  the  Acceptance 
Test/Recovery  Division  identifies  the  needed  fix  for  the 
immediate  recovery  of  inoperable  programs.  In  some  cases, 
the  application  program  developing  organization  applies 
program  fixes.  It  is  emphasized  that  computer  operators  do 
not  perform  program  changes.  The  Acceptance  Test/Recovery 
Division  has  teams  assigned  to  each  application  program  to 
apply  fixes.  This  leads  to  more  knowledgeable  personnel  who 
are  diagnosing  system  problems.  Production  program  files 
can  be  read  by  those  who  need  to,  but  these  files  are  locked 
so  that  only  authorized  personnel  can  modify  the  programs. 
At  NARDAC  Washington,  the  large  volume  of  program  maintenance 
activities  has  made  control  a  difficult  problem. 

Data  Flow  and  Control  -  Exhibit  IV-7  represents  the 
processes  of  data  flow  and  control  at  NARDAC  Pensacola. 
Scheduling  and  quality  control  is  independently  performed 
which  increases  the  control  of  the  data  processing 
operation.  NARDACs  are  trying  to  eliminate  their  involvement 
in  the  data  conversion  process.  Thus,  the  responsibility 
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for  the  accuracy  of  data  rests  with  the  user  and  data 
conversion  should  be  accomplished  by  the  user  or  contract 
personnel.  When  a  job  is  received,  it  must  be  integrated 
into  the  schedule.  After  scheduling,  the  job  must  be  staged, 
based  on  run  documentation  and  using  the  correct  tapes.  The 
production  control  group  monitors  the  schedule  and  the 
progress  of  each  job;  they  also  provide  quality  control  at 
the  level  of  service  specified  and  assure  distribution  or 
transmission  of  the  application's  products.  The 
Teleprocessing  Division  monitors  and  controls  the  network 
during  the  processing  described  above.  Scheduling  is 
accomplished  both  manually  and  mechanically  with  current 
plans  calling  for  a  move  to  a  completely  mechanized  system. 

At  NARDAC  Washington,  the  IBM  group  has  an  automated  IBM 
scheduling  system.  Schedules  are  prepared  in  advance  based 
on  inputed  requirements.  On  the  morning  the  job  is  to  be 
run,  notification  is  transmitted  to  the  user.  The  user  may 
change  the  jobs  within  the  framework  of  the  time  and 
processing  resources  available.  The  automated  system  tells 
the  operations  personnel  the  setup  needed  for  the  job 
including  the  tapes  required.  During  the  day,  the  system 
provides  indications  of  the  time  available  before  the  job 
is  to  be  run  and  records  what  jobs  are  run.  This  type  of 
scheuling  system  can  be  used  to  analyze  production  problems. 

Backup  -  NARDACs  are  entering  into  backup  agreements  with 
other  NARDACs  and  other  data  processing  centers.  However, 
due  to  various  constraints  and  regulations,  excess  capacity 
is  not  readiliy  available  and  the  use  of  another  data 
processing  center's  capacity  will  obviously  degrade  that 
center's  ability  to  provide  the  normal  level  of  service  to 
its  customers.  Priorities  for  service  need  to  be  assessed 
and  instituted.  NARDAC  Washington  has  backup  agreements 
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with  other  government  agencies'  data  processing  centers  in 
the  Washington  area. 


Performance  Measur ement/Ut i 1 i za tion  -  Although  NARDACs 
have  computer  utilization  figures,  such  statistics  do  not 
have  the  importance  that  performance  measurements,  which  are 
customer  oriented,  would  have.  The  Liaison/Planning  Officer 
is  responsible  for  working  to  develop  such  measurements  with 
users.  NARDAC  Washington  uses  its  automated  scheduling 
system  to  analyze  operating  results  which  includes  computer 
downtime.  Reports  of  CPU  useage  are  provided  to  users  and 
in  some  cases,  these  reports  include  dollar  costs  which 
indicate  the  charges  a  user  would  pay  if  the  work  were 
reimburseable. 

Preventive  Maintenance  -  Preventive  maintenance  varies  by 
contractor  and  equipment. 

Training  -  There  are  three  levels  of  training  grades  within 
a  NARDAC.  Individual  Training  Plans  are  developed  and  cross 
training,  on  the  job  training,  schools  and  self-study 
programs  are  the  methods  of  accomplishing  required  training. 

Personnel  -  Regulations  for  the  administration  of  personnel 
are  affected  by  agreements  between  unions  and  the  data 
processing  centers.  Some  NARDACs  operate  under  the  personnel 
management  policies  and  regulations  of  the  Naval  Station  or 
Naval  Air  Station  on  which  they  are  physically  located.  At 
NARDAC  Washington,  personnel  rotate  duties  and,  when 
reasonable,  rotate  among  sites.  Overtime  is  closely 
regulated.  In  general,  it  appears  that  civil  service  rules 
and  employment  stability  tend  to  lessen  the  rotation  of 
duties  among  NARDAC  personnel. 
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Teleprocessing  Network  Configuration  -  An  up-to-date 
configuration  documentation  of  the  teleprocessing  network 
is  available  to  operating  personnel  at  NARDAC,  Pensacola. 
This  document  assists  in  the  troubleshooting  process. 

Standards  -  NARDACs  operate  under  the  following  standards: 

Automated  Data  Systems  Documentation  Standard 
(Department  of  Defense  -  DOD  Instruction  7936.1) 

Security  Requirements  for  Automated  Data  Processing 
Systems  (DOD  Instruction  5200.28) 

ADP  Security  Manual  -  Techniques  for  Implementing, 
Deactivating,  Testing  and  Evaluating  Secure  Resource  - 
Sharing  ADP  Systems  (DOD  Manual  5200. 28M) 

Personnel  Privacy  and  Rights  of  Individuals  Regarding 
their  Personal  Records  (Secretary  of  the  Navy  -  SECNAV 
Instruction  5211.5) 

Department  of  the  Navy  Automatic  Data  Processing 
Program  (SECNAV  Instruction  5230.4) 

Safeguarding  Personal  Information  in  Automated  Data 
Systems.  Includes  Federal  Information  Processing 
Standard  (FIPS)  41  on  the  same  subject  (SECNAV  5239.1) 

Continuity  of  Operations  Policies  and  Planning  (Chief 
of  Naval  Operations  -  OPNAV  Instruction  3050.18) 

Communications  Security  (OPNAV  Instruction  2200.13) 

Automated  Data  System  Development;  Procedures  for  the 
Management  of  (OPNAV  Instruction  5231.1) 
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U.  S.  Navy  Physical  Security  Manual  (OPNAV  Instruction 
5510.45) 

DOD  Industrial  Security  Program  (OPNAV  Instruction 
5540.8) 

Security  of  Federal  Automated  Information  Systems  (OMB 
Circular  No.  A-71) 

Guidelines  for  ADP  Physical  Security  and  Risk 
Management  (FIPS  Pub  31) 

Evaluation  of  Techniques  for  Automated  Personal 
dentif ication  (FIPS  Pub  48) 

Guidelines  for  Automatic  Data  Processing  Risk  Analysis 
(FIPS  Pub  65). 

Reports  -  Activity  reports  are  sent  to  the  user  in  order  to 
determine  if  there  has  been  unauthorized  activity  within 
the  applications  or  the  system  files. 


V.  SYSTEMS  SURVEYS 


This  chapter  summarizes  the  information  obtained  on  distributed 
systems  identified  by  the  Naval  Data  Automation  Command  for  possible 
further  review  during  our  field  work.  The  Naval  Data  Automation  Command 
was  the  primary  source  of  the  information  but  supplemental  information 
was  obtained  from  functional  managers  when  needed  to  complete  the 
survey. 

Our  objective  was  to  review  Navy  developing  distributed  systems 
for  certain  characteristics  which  we  felt  would  provide  the  most 
benefit  to  our  research  effort.  We  were  interested  in  reviewing  systems 
which  had  significant  qualities  of  distributed  systems,  systems  with 
overall  Navy  application,  and  systems  which  were  in  an  advanced  stage 
of  development. 

The  candidate  systems  identified  by  the  Naval  Data  Automation 
Command  were: 

.  Integrated  Disbursing  and  Accounting  (IDA) 

.  Shipboard  Non-Tact ical  ADP  Program  (SNAP) 

.  Pay  and  Personnel  Administrative  Support  System  Phase  II 
(Source  Data  System)  (PASS  Phase  II  [SDS]) 

.  Engineering  Field  Division  Management  Information  System 
(EFD/MIS) 

.  Public  Works  Center  Management  Information  System  (PWC/MIS) 
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.  System  Stock  Point  Logistics  Integrated  Communications 

Environment  (SPLICE) 

.  Naval  Aviation  Logistics  Command  Management  Information 
System  (NALCOMIS) 

In  the  remainder  of  this  chapter  we  discuss  the  types  of 
information  obtained  on  the  systems  surveyed  and  briefly  discuss  the 
two  systems  selected  for  further  review.  We  have  divided  our  discussion 
into  the  following  sections: 

.  System  Information  Obtained 

.  Systems  Selected. 

Each  topic  is  presented  below. 

1.  SYSTEM  INFORMATION  OBTAINED 


In  order  to  evaluate  the  distributed  systems  under  development 
within  the  Navy,  survey  information  was  obtained  on  each  system 
identified  as  a  distributed  system  by  the  Naval  Data  Automation 
Command.  Our  purpose  in  obtaining  this  informtion  was  to  select  for 
further  study  systems  which  best  fit  our  project  objectives. 

Below  we  present  the  types  of  information  we  obtained  on  each 
system  and  a  brief  explanation  of  each  category. 

•  Type  of  System 

A  brief  description  of  the  principal  type  of  data  which  the 
system  processes,  e.g.,  financial,  logistical,  supply, 
informational,  etc.  The  type  of  data  processed  is  indicative 
of  the  level  of  internal  control  needed. 
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System  Description  and  Objectives 

This  category  briefly  states  the  basic  purpose  of  the  system 
and  describes  the  system  and  its  distributed 
characteristics. 

System  Status 

This  item  indicates  the  development  status  of  the  system  in 
terms  of  life  cycle  management  stages  of  development.  A 
graphic  overview  of  the  development  status  of  the  systems 
reviewed  is  provided  by  Exhibit  V-l. 

Design  Agency 

Here  we  identify  the  agency  which  is  designing  the  system 
or  the  agency  performing  the  duties  of  a  functional  manager, 
that  is  managing  other  organizations  responsible  for  the 
system  design. 

User  Agency 

Here  we  identify  the  agency  or  the  agencies  which  will 
receive  the  products  of  the  data  processing  system  under 
development. 

Location  of  Demonstration  Site 


This  item  identifies  the  command  and  physical  location  of 
the  systems  under  review. 

Documentation  Available 


Any  pertinent  documentation  available  at  the  Naval  Data 
Automation  Command  is  listed  under  this  caption. 
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The  information  obtained  from  the  Naval  Data  Automation  Command 
was  considered  to  be  an  adequate  survey  of  non-tactical  distributed 
systems  under  development  in  the  Navy.  No  systems  which  were 
operational  were  identified  as  can  be  seen  from  a  review  of  Exhibit 
V-l .  The  Detail  results  of  our  initial  survey  are  presented  in  Appendix 
C  of  this  volume  of  our  report.  The  categories  of  information 
previously  described  are  presented  for  each  of  the  seven  systems  we 
considered  for  further  review.  In  the  next  section  we  briefly  discuss 
the  system  we  selected  for  a  more  in-depth  review. 
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SYSTEMS  SELECTED 


After  completing  our  survey  at  candidate  systems,  we  selected  IDA 
and  PASS  Phase  Il/SDS  for  a  more  in-depth  review.  The  objectives  of 
our  review  were  to  develop  an  understanding  of  the  flow  of  data  through 
these  systems  and  to  identify  key  control  points  within  the  systems. 
The  details  of  our  review  of  these  systems  are  presented  in  Appendices 
A  &  B  of  this  report.  In  the  remainder  of  this  chapter  we  briefly 
discuss  these  two  systems. 


Integrated  Disbursing  and  Accounting/Financial  Management 


We  selected  IDA/FMS  because  it  was  a  system  which  was  well 
advanced  in  the  system  life  cycle  process.  With  an 
operational  IDA  system  developed  at  CNET,  it  was  possible 
to  develop  an  accurate,  complete  understanding  of  the  system 
characteristics  and  discuss  system  operations  with  IDA/FMS 
designers,  system  users  and  data  processing  center  operators 
who  had  actual  experience  with  the  system.  The  IDA  concept 
utilizes  regional  financial  information  processing  centers 
which  provide  both  accounting  and  disbursing  services  to 
financial  regions.  These  regional  centers  will  eventually 
be  linked  to  each  other  and  to  a  central  accounting  and 
finance  office  using  a  telecommunications  network.  The  IDA 
System  we  reviewed,  was  called  IDA/FMS.  The  FMS  portion  of 
the  system  was  developed  within  CNET  several  years  ago  and 
the  IDA  portion  added  in  1977.  The  completed  package  is 
known  as  IDA/FMS  and  is  the  accounting  system  of  the  future 
for  the  Navy.  The  Comptroller  of  the  Navy  has  partially 
certified  the  system  and  plans  call  for  IDA/FMS  to  be 
exported  to  other  regions  within  the  Navy.  For  this  reason 


we  chose  IDA/FMS  as  representative  of  the  type  of  Financial 
System  the  Navy  will  have  in  the  future. 

PASS  PHASE  II/SDS 

PASS  Phase  Il/SDS  is  designed  to  automate  the  overall  Navy 
Military  personnel  and  pay  management  information  system 
and  to  improve  the  quality  and  timeliness  of  management 
information.  Although  the  PASS  Phase  Il/SDS  system  is  in 
an  early  stage  of  system  development,  it  was  considered  a 
significantly  advanced  system  with  an  interfacing  capability 
with  two  headquarters  data  bases.  Since  there  is  presently 
no  PASS  Phase  Il/SDS  system  operating,  the  discussion  of 
this  system  is  based  on  information  obtained  from  the  PASS 
project  office  personnel.  We  can  not  discuss  specific 
operational  controls  at  a  detailed  level  but  only  mention 
the  plans  of  the  project  team. 

PASS  Phase  II  is  a  distributed  data  processing  system  with 
distributed  data  bases.  PASS  field  offices  will  have 
terminals  linked  to  field  host  processors  at  Data  Processing 
Centers.  These  field  host  processors  will  maintain  pay  and 
personnel  data  bases  and  interact  with  the  MAPTIS  and  JUMPS 
system  through  headquarters  Host  Processors.  The  system 
will  utilize  an  extensive  telecommunications  network  and 
features  two  way  updating.  File  transactions  will  flow  from 
the  field  offices  upward  as  well  as  from  Headquarters  down. 

The  review  of  PASS  Phase  Il/SDS  and  IDA/FMS  has  been  most  useful 
to  our  project  team.  Although  we  have  not  audited  these  systems,  we 
have  gained  a  level  of  understanding  regarding  the  system  features 
and  the  flow  of  data  through  these  systems.  With  both  system  being 
relatively  young  in  terms  of  the  life  cycle  of  a  system,  it  has  provided 
us  with  the  opportunity  to  understand  how  Navy  Systems  are  developed, 
as  well  as  providing  an  overview  of  specific  systems. 


VI.  OBSERVATIONS  AND  CONCLUSIONS 


The  purpose  of  this  chapter  of  our  report  is  to  present  our 
observations  and  conclusions  relative  to  the  Navy's  ADP  environment. 
The  discussions  contained  in  this  chapter  are  a  compilation  of 
information  we  have  gathered  during  Task  2  of  our  project.  The 
remainder  of  this  chapter,  we  present  a  summarizes  our  observations 
and  conclusions. 

1.  OBSERVATIONS 


The  observations  presented  below  are  related  to  the  Navy's 
existing  ADP  environment  and  related  internal  controls.  The  items 
outlined  below  have  a  significant  impact  on  general  internal  controls 
in  an  advanced  systems  environment. 

.  The  Navy's  System  Development  Process  Provides  a  Well 

Controlled,  Managable  Procedure  for  Developing  ADP  Systems. 

Controls  over  the  system  development  process  are  necessary 
for  several  reasons.  Obviously,  a  controlled  system 
development  effort  is  easier  to  manage  and  evaluate.  The 
management  aspects  include  budgetary  and  schedule 
compliance.  Another  benefit  is  the  ability  to  review  and 
institute  needed  controls  in  the  system  being  developed.  A 
sound  system  development  process  provides  this  opportunity. 
Finally,  a  good  system  development  process  provides  for 
adequate  testing  of  an  application's  controls  prior  to 
implementation.  These  aspects  of  system  development  control 
increase  the  reliability  of  the  system  and  lead  to  better 
application  systems. 
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We  have  reviewed  the  Navy's  AIS  development  process  and 
discuss  certain  aspects  of  it  in  more  detail  in  Chapter  III 
of  this  volume.  In  general,  we  believe  the  system  development 
process  utilized  in  the  Navy  provides  the  general  benefits 
previously  described  in  this  section.  The  opportunity  to 
control  and  management  system  development,  the  ability  to 
assure  adequate  system  controls  and  the  opportunity  to 
evaluate  system  design  and  testing  are  all  present  in  the 
Navy's  AIS  development  process. 

NAVDAC's  Initiatives  in  the  Area  of  the  ADP  Security  Manual 


and  the  ADP  Inspection  Guide  are  Positive  Steps  Towards  a 


Well-Controlled  ADP  Operating  Environment. 


The  Navy's  ADP  Security  Manaual  is  designed  to  establish  the 
Navy's  security  program  for  ADP  systems  and  to  serve  as  a 
management  tool  by  consolidating  pertinent  Navy  ADP  security 
information.  It  contains  policies,  responsibilities,  and 
procedures  for  Navywide,  Command,  and  Activity  ADP  security 
programs  and  provides  guidance  for  those  charged  with 
implementing  policies  and  procedures.  The  manual  is  also 
designed  to  provide  guidance  in  developing  and  applying 
cost-effective  security  measures  related  to  ADP  systems  and 
data. 

The  NAVDAC  Inspector  General  is  preparing  an  ADP  inspection 
guide.  This  guide  incorporates  requirements  from  various 
instructions  and  publications  and  integrates  them  into  one 
document.  This  inspection  guide  also  includes  the  GAO  Audit 
Guide  requirements  for  ADP  systems. 


These  initiatives  are  significant  undertakings  and  should 


VI-2 


increase  the  level  of  security  awareness  in  the  Navy's  ADP 
environment.  Guidance  in  the  area  of  security  comes  from 
multiple  sources  in  the  Federal  Government  3nd  efforts  to 
consolidate  and  explain  responsibilities  benefit  the  entire 
Navy.  Security  is  an  important  aspect  of  the  system  of 
internal  controls  and  these  NAVDAC  efforts  have  a  positive 
impact  on  all  aspects  of  the  Navy's  ADP  operations. 

The  Standard  NARDAC  Organization  Provides  a  Well-Controlled 
Operating  Environment. 

Controls  in  the  operation  of  computer  centers  are  needed  to 
compliment  the  controls  placed  in  specific  application 
systems.  General  controls  should  operate  in  the  computer 
center  to  assure  the  reliability  of  hardware  equipment,  and 
the  availability  of  files  and  application  programs  to 
perform  daily  processing. 

We  have  discussed  the  NARDAC  operating  environment  with 
representatives  of  two  NARDAC  organi tat  ions.  The  procedural 
and  organ i za t iona 1  controls  necessary  to  assure  a  controlled 
operating  environment  are  supported  by  the  individuals  we 
met.  The  changes  necessary  to  support  such  an  operating 
environment  are  in  the  process  of  being  instituted  at  the 
NARDAC  facilities.  We  realize  this  is  an  evolutionary 
process  which  requires  time  and  a  sustained  effort.  The 
resources  required  to  improve  the  NARDACs  have  been  provided 
and  the  effort  appears  to  be  well  underway.  We  hope  the 
enthusiasm  and  dedication  to  this  reorganization  is  shared 
by  all  NARDACs  throughout  the  Navy.  The  development  of  well 
organized,  controlled  processing  centers  should  increase 
user,  designer,  and  management  confidence  in  the  Navy's  ADP 
processing  capability. 
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The  Institution  of  a  Test  and  Acceptance  Group  and  the  Levels 
of  Service  Concept  will  Define  Responsibilities  in  the  ADP 
Systems  Area  and  Permit  Operating  Standards  to  be  Enforced. 

Under  the  present  operating  concept,  NARDACs  have  provided 
ADP  processing  for  user  activities  regardless  of  the  quality 
of  the  application.  A  feature  of  the  new  NARDAC 
organizational  structure  will  be  a  test  and  acceptance 
group.  This  group  will  provide  an  independent  evaluation 
of  user  applications  and  determine  if  applications  will 
operate  successfully  in  the  NARDAC  environment.  This 
independent  performance  review  provides  the  computer 
processing  center  an  opportunity  to  reject  applications 
which  are  poorly  designed,  consume  excessive  CPU  time,  and 
burden  processing  center  operations. 

Another  related  concept  planned  for  the  NARDAC  operating 
environment  is  the  levels  of  service  concept.  Under  this 
method,  users  are  provided  with  options  as  to  what  services 
and  what  grade  of  service  they  wish  to  receive  from  the 
NARDAC.  Responsibilities  are  accepted  by  the  user  or 
assigned  to  the  NARDAC.  This  methodology  allows  NARDAC 
personnel  to  explain  the  range  of  services  available  and 
users  must  accept  responsibility  for  the  aspects  of  the 
system  he  chooses  to  retain. 

The  combination  of  these  two  concepts  will  provide  several 
improvements  in  the  operational  aspects  of  Navy  ADP  systems. 
Application  performance  will  be  evaluated  by  the  processing 
center.  Responsibility  for  various  aspects  of  system  design 
and  operation  will  be  more  clearly  defined.  Computer  center 
performance  can  be  effectively  measured.  All  of  these 
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inhancements  should  increase  the  quality  and  operational 
efficiency  of  Navy  ADP  systems. 


The  Risk  Assessment  Should  Provide  Increased  Awareness  in 
the  Area  ADP  Security  and  Lead  to  a  More  Controlled 
Environment. 


As  required  by  NAVDAC,  NARDACs  are  currently  in  the  process 
of  performing  risk  assessments.  The  risk  assessment  is  a 
systematic  approach  to  making  security  decisions.  This 
analysis  includes  identification  of  system  components  or 
functions  which  have  weaknesses,  analysis  of  potential 
threats  to  the  system,  identification  of  countermeasures  and 
the  cost-effectiveness  of  these  countermeasures,  and  the 
identification  of  residual  vulnerabilities. 

The  performance  of  a  risk  assessment  is  time  consuming  and 
requires  the  dedication  of  human  resources.  However,  the 
results  of  such  an  analysis  provide  increased  awareness  of 
the  security  aspects  of  data  processing  operations  and 
identify  the  most  cost  effective  methods  of  dealing  with 
exposures.  This  analysis  is  valuable  and  provides  an 
opportunity  to  improve  security  consciousness  among  all  data 
processing  center  personnel. 

Due  to  the  Nature  of  the  Navy  Environment  There  Should  be 
Central  Guidance  Related  to  Internal  Controls  Available  to 
System  Design  Agencies. 

When  developing  our  system  descriptions  of  Navy  distributed 
systems,  we  were  interested  in  what  sources  the  design 
agencies  were  utilizing  in  determing  what  internal  control 
features  would  be  placed  in  the  systems.  There  were  a  variety 
of  sources  presented  and  the  system  of  internal  controls 
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built  into  the  systems  we  reviewed  appear  to  be  adequate, 
but  no  central  source  of  guidance  was  consistently  named. 
We  feel  that  the  Navy  should  develop  a  source  for  internal 
control  guidance.  Obviously,  no  one  set  of  internal  controls 
can  or  should  be  built  into  every  operating  system.  However, 
a  central  source  could  provide  general  internal  control 
guidance  to  system  designers,  discuss  alternative  available 
in  various  system  control  aspects,  and  outline  the  system 
features  and  data  character istics  which  impact  the  need  for 
specific  controls.  This  central  guidance  should  increase 
the  quality  of  overall  Navy  systems  and  fix  the 
responsibility  for  maintaining  up-to-date  guidelines  for 
system  developers  to  reference. 


The  Navy  ADP  System  Development  Process  Should  Be  Supported 
by  Increased  Audit  Service  Involvement  in  the  System 
Development  Process 

In  the  system  development  process,  which  all  major  Navy  ADP 
systems  must  follow,  there  are  several  stages  where  the  Naval 
Audit  Service  should  be  involved.  Involvement  is  defined 
in  terms  of  providing  service  to  management  in  a  consultant 
role.  The  exposure  necessary  to  provide  this  sevice  could 
be  included  in  the  Navy's  ADP  security  manual.  We  reviewed 
a  draft  copy  of  this  manual  which  had  a  small  section  on 
the  Audit  Service  and  it's  responsibility  to  "ensure  the 
system  will  be  auditable"  during  system  design.  This 
requirement  to  respond  to  the  system  designer  during  the 
system  concept  design  is  an  opportunity  the  Audit  Service 
should  exploit.  The  Audit  Service  should  provide  an  auditor 
to  the  system  designer  who  is  knowledgeable  concerning 
system  development  with  the  idea  of  emphasizing  internal 
controls  in  an  ADP  system  as  a  management  tool  as  well  as 
an  auditability  feature.  By  involving  the  auditor  at  this 


early  phase  of  system  development,  constructive  input  can 
be  provided.  This  will  not  only  enhance  the  quality  of  the 
ultimate  system,  but  increase  the  esteem  of  the  Audit  Service 
with  the  system  design  agency. 

The  Audit  Service  Should  Write  the  Section  on  the  Naval 
Audit  Service  for  the  ADP  Security  Manual 

The  Audit  Service  should  identify  it's  mission  and 
capabilities  in  the  ADP  Security  Manual.  This  document,  with 
its  wide  circulation,  provides  the  Audit  Service  an 
opportunity  to  discuss  not  only  audit  requirements  but 
internal  controls  in  general.  The  Audit  Service  may  wish 
to  expanded  this  section  of  the  Security  Manual  to  include 
a  brief  discussion  of  the  concept  of  internal  controls  and 
the  increased  need  for  awareness  in  the  design  of  advanced 
ADP  systems. 

The  chapter  as  presently  written  discussed  audit  trails, 
system  aud i t i ab i 1 i ty,  audit  requirements,  audit  review,  audit 
controls,  and  audit  testing.  These  items  are  not  defined 
and  may  lead  to  confusion  among  system  designers  who  are 
data  processing  oriented,  not  audit  professionals.  We 
recommend  the  Audit  Service  participate  in  the  development 
of  the  ADP  Security  Manual  and  clearly  identify  it's  purpose 
in  participating  in  the  system  development  process. 

2.  CONCLUSIONS 


As  previously  stated,  Task  2  was  designed  to  guide  our  research 
efforts  in  order  to  provide  the  Navy  with  the  most  useful  product.  It 
was  imperative  that  we  understand  the  direction  the  Navy  was  headed 
in  order  to  properly  direct  our  research  efforts.  The  conclusions 
which  follow  identify  areas  of  emphasis  which  will  influence  our 


efforts  during  Tasks  4  and  5  of  our  field  work.  In  the  remainder  of 
this  chapter,  we  presents  our  conclusions  and  briefly  discuss  each 


item. 


Developing  Navy  Systems  will  Change  the  Nature  of 
Traditional  Audit  Approaches 


Our  research  related  to  advanced  EDP  systems  has  made  this 
point  very  clear.  Traditional  audit  approaches  will  not  be 
sufficient  in  a  distributed  environment.  The  distribution 
of  data,  input  capability  and  the  utilization  of 
communications  links  require  a  modification  to  the 
traditional  audit  approach.  Distributed  systems  place  an 
increased  emphasis  on  audit  capability  being  provided  for 
in  the  system's  design  and  the  traditional  audit  approach 
must  be  modified. 

There  is  a  Greater  Need  for  Audit  Involvement  in  the  System 
Development  Process 

One  of  our  observations  presented  in  Volume  2  of  this  report 
relates  to  the  increased  significance  of  the  system  design 
phase  in  distributed  systems.  The  analysis  performed  during 
this  phase  must  adequately  address  the  desirability  of 
individual  internal  controls.  System  design  should  not  only 
incude  this  evaluation  of  internal  controls  but  also 
identify  the  features  needed  to  facilitate  the  verification 
of  such  controls.  Thus  system  auditability  is  an  important 
aspect  of  the  design  of  application  systems  and  increased 
audit  involvement  is  required.  In  order  for  such  involvement 
to  be  successful  the  auditor  must  understand  the  system 
development  process  and  be  capable  of  conveying  audit 
objectives  in  terms  data  processing  professionals  can 
understand. 
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Continuinq  Proiect  Efforts  will  Emphasize  the  Impact  of 


Distributed  Systems  on  the  Navy's  Developinq  EDP  Environment 


and  How  the  Audit  Service  can  Best  Serve  the  Navv  in  This 


Situation 


Our  knowledge  of  Navy  ADP  operations,  types  of  systems  being 
developed  and  Naval  Audit  Service  practices  and  procedures 
will  significantly  influence  our  remaining  project  efforts. 
We  will  be  able  to  evaluate  the  applicability  of  our 
recommendatons  with  sufficient  understanding  of  where  the 
Navy  presently  stands  and  where  it  appears  to  be  headed. 
This  insight  will  temper  our  analysis  and  provide  necessary 
guidance. 


Our  future  efforts  will  not  focus  on  individual  Navy 
applications  but  the  developing  environment  at  advanced  EDP 
systems.  Emphasis  will  be  placed  on  the  Auditor's  approach 
and  auditing  techniques  which  are  most  effective  in  this 
technologically  advanced  environment. 
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INTEGRATED  DISBURSING  AND  ACCOUNTING  SYSTEM 

(IDA) 


SYSTEM  DESCRIPTION 


The  purpose  of  this  system  description  is  to  present  our 
understanding  of  the  Navy's  Integrated  Disbursing  and  Accounting 
Financial  Management  System  (IDA/FMS)  developed  by  the  Naval  Education 
and  Training  Command  (CNET)  at  the  Naval  Air  Station  in  Pensacola, 
Florida.  The  IDA  concept,  developed  by  the  Navy  Comptroller's  Office, 
has  as  its  primary  objective  to  integrate  the  disbursing  and  accounting 
functions  while  improving  the  timeliness  and  accuracy  of  financial 
information  for  Navy  managers.  The  Office  of  the  Comptroller  of  the 
Navy  has  issued  a  general  design  document  for  the  IDA  concept.  The 
purpose  of  this  general  design  is  to  provide  guidelines  and  standards 
for  the  overall  processing  network  for  the  internal  and  external  flow 
of  financial  data.  A  detailed  design  manual  was  also  developed  by 
NAVCOMPT  to  state  the  Navy's  objectives,  policies,  guidelines 
principles  and  standards  for  the  design,  development  and  implementation 
of  a  financial  processing  network  for  internal  and  external  data  flow. 
Based  on  these  two  documents,  operating  level  systems  are  to  bt 
developed.  One  of  these  operating  level  systems  is  the  Naval  Education 
and  Training  Integrated  Disbursing  and  Accounting  Financial  Management 
System  (IDA/FMS).  In  order  to  facilitate  our  description  of  this 
system,  we  have  divided  our  discussion  into  the  following  categories: 

.  Background  and  System  Overview 


System  Documentation  and  Users  Manual 


Source  Document  and  Input  Preparation 


.  Data  Conversion 

.  System  Interfaces 

.  System  Edits 

.  Error  Corrections 

.  Data  Base 

.  System  Reporting  and  Inquiry  Capabilities 
•  Data  Reconciliations. 

A  discussion  of  each  subject  is  presented  below. 

1.  BACKGROUND  AND  SYSTEM  OVERVIEW 


The  Navy's  present  disbursing  and  accounting  systems  evolved  from 
the  World  War  II  period.  The  disbursing  function  was  established  as 
a  separate  system  in  order  to  provide  prompt  payment  to  contractors 
for  goods  and  services  rendered  to  support  the  war  effort.  This  system 
has  not  changed  since  that  time.  The  Navy's  official  accounting 
function  has  traditionally  been  performed  by  Author ization  Accounting 
Activities  (AAAs).  Within  the  Navy  there  are  over  250  AAAs  responsible 
for  maintaining  official  accounting  records  for  approximately  1300 
Navy  operating  budget  holders  or  fund  administering  activities. 
Exhibit  A-l  which  follows  this  page  illustrates  the  present  flow  of 
financial  information  within  this  structure.  Although  this  system  has 
met  the  external  reporting  requirements  imposed  on  the  Navy,  the 
physical  and  organizational  separation  of  the  disbursing  and 
accounting  functions  has  precluded  the  financial  system  from  meeting 
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the  informational  requirements  of  Savy  managers.  This  system  has  also 
resulted  in  numerous  other  deficiencies  in  the  accounting  and 
disbursing  processes  in  the  Navy.  A  summary  of  these  deficiencies  is 
presented  in  the  following  listing: 

.  Multiple  recording  of  the  same  detailed  data  at  disbursing, 
accounting  and  operating  activities 

.  Untimely  Financial  Data 

.  High  support  cost  associated  with  the  preparation, 

transmission  and  processing  of  hard  copy  documentation 

.  Multiple  reconciliation  of  both  disbursing  and  accounting 
data 

.  Excessive  balance  of  undistributed  disbursements. 

The  IDA  concept  utilizes  regional  financial  information  processing 
centers  which  provide  both  accounting  and  disbursing  services  to 
financial  regions.  These  regional  centers  will  eventually  be  linked 
to  each  other  and  to  a  central  accounting  and  finance  office  using  a 
telecommunications  network.  The  financial  processing  centers  are 
linked  to  local  activities  via  Cathode  Ray  Tube  (CRT)  terminals  to 
provide  on-line  inquiry  and  to  update  files  where  appropriate.  This 
networking,  illustrated  in  Exhibit  A-2,  provides  the  following 
benef its : 

.  One  Time  Data  Capture  -  Under  the  IDA  concept,  data  is 

inputted  to  the  system  via  remote  terminal  devices.  The 
source  documents  associated  with  this  input  are  retained  at 
the  input  stations,  thus  eliminating  the  transmissions  of 
hard-copy  accounting  documents. 
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under  IDA  Concept 
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.  Establishment  of  a  Single  Document  File  (Data  Base)  -  The 
IDA  data  base  provides  many  advantages  during  processing  as 
well  as  on-line  inquiry  capability.  A  complete  description 
of  the  Data  Base  and  a  discussion  of  its  advantages  is 
presented  in  a  subsequent  section  of  this  system 
description. 

.  Maximum  Utilization  of  Teleprocessing  and  ADP  Capabilities 

The  IDA  system  provides  improved  utilization  of  ADP 
capabilities  and  increases  the  quality  of  output  for  users, 
other  systems  and  higher  management.  The  benefits  in  this 
area  are  mentioned  throughout  the  system  description. 

.  Automation  of  the  Payment  Certificate  Process  -  The  IDA 

system  automates,  to  the  maximum  extent  possible,  the  payment 
certification  process  presently  manually  performed. 

.  Improved  Financial  Management  Reporting  to  Local  and  Higher 
Levels  of  Management. 

An  overview  of  the  IDA/FMS  system  is  presented  in  Exhibit  A-3. 

As  the  flowchart  in  Exhibit  A-3  shows,  the  IDA/FMS  system  consists  of 
two  major  processing  cycles,  the  IDA  module  and  the  FMS  module.  The 
IDA  module  includes  the  following  proceses : 

.  Batch  Balancing 

.  Edit/Validation 

.  Payment  Certification 

.  Reformat  and  Update 
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System  Overview  Flowchart 


EXHIBIT  A-3 
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The  accounting  module  (FMS),  which  utilizes  files  produced  during  the 
IDA  module,  includes  : 

.  Updating  of  accounting  ledgers  and  other  files 
Storage  of  Details 

•  Production  of  various  reports  and  journals. 

The  two  basic  processing  steps  in  the  IDA  module  are  che  payment 
certification  process  and  the  disbursing  process.  All  input  data  is 
batch  balanced  and  subject  to  extensive  machine  edits  prior  to 
processing.  IDA  outputs  include  reports  for  controlling  input  data, 
transactions  for  updating  accounting  records  and  management  reports 
for  local  and  higher  management.  The  IDA  data  base  permits  on-line 
inquiry  capability  to  selected  data  elements  to  provide  current  status 
of  commercial  contracts  and  invoices,  the  major  items  processed  are 
dealer  invoices  and  travel  vouchers  for  payment.  The  IDA  concept  was 
developed  based  on  the  fundamental  concepts  promulgated  in  NAVSO  P- 
3583.  The  FMS  section  of  the  system  utilizes  files  updated  during  the 
IDA  processing  and  input  provided  by  the  supply  system  FMS  basically 
updates  accounting  ledgers,  stores  details  and  produces  various  reports 
and  journals.  The  resulting  system,  IDA/FMS,  has  successfully 
integrated  the  disbursing  and  accounting  functions. 

The  IDA/FMS  system  was  developed  to  operate  on  an  IBM  360/65 
located  at  NARDAC  Pensacola  with  CRTs  and  printers  located  in  the 
users  offices  which  IDA/FMS  supports.  The  IDA/FMS  system  operates 
daily  and  provides  output  data  for  other  accounting  systems  in  a  card 
or  tape  format.  This  IDA/FMS  development  effort  has  been  reviewed  and 
approved  by  the  Comptroller  of  the  Navy  who  coinitiated  the  effort 
wi-h  CNET  in  April  of  1976.  Although  future  plans  call  for  the  addition 

A- 5 


of  minicomputer  to  the  system  this  capability  does  not  presently  exist. 
This  system  description  is  based  on  the  current  system  conf iguration 
and  equipment  presently  in  place. 

2.  SYSTEM  DOCUMENTATION  AND  USERS  MANUALS 

We  have  reviewed  several  documents  specifically  developed  for 
the  IDA/FMS  system  at  Pensacola.  This  documentation  is  believed  to 
be  complete  and  accurate  and  provides  a  good  understanding  of  the 
IDA/FMS  system.  The  documentation  was  well  indexed,  easy  to  understand, 
and  contained  graphics  and  tables  to  facilitate  understanding.  The 
documentation  listed  below  was  reviewed. 


Title 

Document  Numbers 

Date 

IDA/Functional  Description 

NAS  P-104 

FD-01 

1-Dec  76 

IDA/Users  Manual 

NAS  P-104 

U.M-01 

1  Oct  77 

IDA/ System/Subsystem 
Specification 

68142-E80 

SS-01 

1  Oct  77 

IDA/Data  Base  Specifications 

68546-E80 

DS-01 

1  Oct  77 

IDA/Data  Requirements  Document 

68142-E80 

RD-01 

1  June  77 

IDA/ Computer  Operation  Manual 

68540-E80 

OM-01 

1  Oct  77 

FMS/Functional  Description 

NETISA  00062-90 
FD01 

31  Mar  76 

FMS/IDA  CRT  Users  Guide 

00062-090 

UG-013 

9  Feb  7  9 

3.  SOURCE  DOCUMENTS  AND  INPUT  PREPARATION 

The  purpose  of  this  section  is  to  identify  the  source  documents 
and  Input  Preparation  Activities  associated  with  the  IDA/FMS  system. 
There  are  six  basic  classifications  for  source  documents  utilized  by 
the  IDA  module.  They  are: 
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Auxiliary  Appropriation  Data 


.  Contractor  Information  and  Status  Data 

•  Check  Register  Data 

.  Parameter  Data 

.  Obligation  Data 

.  Payment  Data. 

Each  of  these  input  types  is  discussed  below. 

•  Auxiliary  Appropriation  Data 

Appropriation  Data  is  required  for  all  appropriations  other 
than  CNET  accounted  for  by  AAA  68566.  This  data  is  required 
for  each  expenditure  processed  and  must  be  inputted  upon 
receipt  of  the  obligating  documents  if  the  appropriation 
has  not  previously  been  established  on  the  system.  The 
NETFIPC  IDA  Branch  is  responsible  for  the  updating  of  the 
appropriation  file  based  on  the  accounting  classification 
cited  on  the  obligation  document.  Obligation  documents  are 
discussed  under  a  subsequent  heading  in  this  section.  The 
information  is  established  by  the  use  of  the  CRT  for  on¬ 
line  updates. 

.  Contractor  Information  and  Status  Data 

Contractor  information  and  status  is  required  for  obtaining 
the  proper  name  and  address  for  each  check  produced  by  the 
IDA  system.  The  contractor  status  is  a  system  feature  which 
prevents  payments  to  a  contractor  who  is  bankrupt  or  indebted 
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to  the  U.S.  Government.  The  NETFIPC  branch  also  inputs 
Contractor  Information  data  using  the  CRT  for  on-line 
updates . 


Obligation  Data 

Obligation  data  is  input  daily  by  the  Comptroller  of  each 
customer  activity  and  by  the  AAA  technicians  at  NETFIPC  for 
activities  whose  data  volume  does  not  warrant  the  use  of  a 
terminal.  The  AAA  68566  obligation  data  is  input  via  CRTs, 
while  satellite  activities  utilize  similar  equipment  for 
their  input.  A  listing  of  source  documents  and  their  form 
numbers  are  presented  in  Exhibit  A-4.  The  system  will  reject 
this  input  unless  the  contractor  data  and  appropriation  data 
previously  discussed  in  this  section  has  already  been 
established  on  the  system. 

Payment  Data 

Payment  input  is  required  to  record  all  invoices,  travel 
advances/ liquidations,  collections,  refunds,  adjustments  and 
reimbursable  billing  for  which  expenditures  must  be 
processed.  Transactions  which  require  disbursement  of  funds 
will  result  in  the  production  of  system  produced  checks  if 
the  obligation  data  previously  discussed  has  been 
established  on  the  system.  The  CNET  NETFIPC  Branch  is 
responsible  for  processing  this  input,  which  is  input  via 
CRTs.  Preparation  is  daily  upon  the  receipt  of  check  or 
cash  for  collections  and  refunds,  receipt  of  travel 
advances/ liquidations,  receipt  of  reimbursable  billing  and 
receipt  of  adjustment  transactions.  All  payment  input 
details  must  be  preceded  by  a  batch  header. 

Parameter  Data 


EXHIBIT  A-4 
Page  1  of  3 


LIST  OF  SOURCE  DOCUMENTS  FOR  IDA  FMS  INPUTS 


_ Title  of  Document _ 

Award/Contract 
Purchase  Order 

TDY  Travel  of  DOD  Personnel;  Request  and 
Authorization  for 

Architect  -  Engineer  Fixed-Price  Contract 
Shipping  Document;  Requisition  and  Invoice 
Project  Order 

Accounting  Data;  Summary  of 

DOD  Printing  Requisition  Order 

Contractual  Procurement;  Request  for 

DOD  Civilian  Permanent  Duty  Travel; 

Request  and  Authorization  for 

TAD  Travel  Order 

Work  Request 

Contract  Amendment,  Modification 
Standard  Transfer  Order 
Contract  Form 

Expenditures  on  Official  Business;  Claim  for 
Reimbursement  for 

Single  Line  Item  Requisition 

Reimbursable  Work  Orders 

Blanket  Purchase  Agreement  Call 

Military  Interdepartmental  Purchase  Request  (MIPR) 
Infuels  Into-plan  Contract  Sales  Slip 


Form  No. 

SF  26 
DD  1155,  SF  44 
DD  1610 

SF  23 
DD  1149 
NC  2053 
NC  2035 
DD  282 
NC  2038 
DD  1614 

NAVPERS 

1230/16 

NC  140 

SF  30 

NC  5  36 

SF  33 

SF  1164 

DD  1348 
Various 
Various 
DD  448-2 
DD  1898 
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LIST  OF  SOURCE  DOCUMENTS  FOR  IDA  FMS  INPUTS  (Continued) 


Title  of  Document 


Form  No. 


Fuels  Issue/Defuel  Contract  Slip 

Transfer  Between  Appropriations  and/or  Funds 

Navy  Bill 

Cash  Collection  Voucher 
Travel  Voucher,  sub-voucher 
Reimbursement  voucher 
Public  Vouchers 

Disbursing  Officer  Vouchers  (DOVs) 

Vendors  Invoices  (Dealer's  Bills) 

Shipment  and  Performance  Notice  (SPN) 

Labor  Distribution  Card 

Contractors  Request  for  Progress  Payments 

Resources  Authorization 

Al lotment/sub- Allotment  Authorization 

Funded  Reimbursable  Work  Estimate 

Material  Inspection  and  Receiving  Report 
Initiation,  Bid  &  Award 
Continuation  Sheet 

Withdrawals  and  Credits;  Voucher  and  Schedule  of 
Schedule  of  Voucher  Deductions 


AF  1994 

SF-1080 

NC- 252 

DD  1311 

DD  1351 

SF  1129a 

Various 
(SF  1034) 

Various 

Various 

Various 

Various 

Various 
(DD  1195) 
(DD  548) 

NAVCOMPT 

2168-1 

NAVCOMPT 

372 

NAVCOMPT 

2044 

DD  250 

SF  19 

SF  36 

SF  1081 

SF  1096 


Correction  Notice 


NAVCOMPT 

621 
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LIST  OF  SOURCE  DOCUMENTS  FOR  IDA  FMS  INPUTS  (Continued) 


Title  of  Document 


Form  No. 


Expenditure  Cards 

Expenditures/Collections;  Listing  of 

Labor  Roll/Material  Charges  &  Credits 

Fund  Authorization  Charges 

Military  Service  Report 

Schedule  of  Cancelled  Checks 
Advice  of  Payment 
Procurement  Document  Transmittal 
Labor  Job  Time  Card 


NAVCOMPT 

632 

NAVCOMPT 

634 

NAVCOMPT 

2051 

NAVCOMPT 

2074 

NAVCOMPT 

2182 

SF  1098 

DSA  477 

N A VS UP  631 

NAVDOCKS 

1950 


NAVCOMPT 
7000  Series 


Parameter  card  data  is  required  to  control  the  check  numbers 
issued  by  the  system.  The  CNET  NETFIPC  branch  prepares  the 
parameter  card  data  on  a  preprinted  form  which  will  then  be 
punched  by  the  NARDAC  I/O  control  group. 


Miscellaneous  Labor  and  Work  Unit  Data 


Biweekly  information  concerning  labor  adjustments  and  work 
units  is  provided  to  the  IDA/FMS  system.  This  information 
is  needed  to  produce  accurate  management  reports  regarding 
public  works  projects. 

There  is  additional  input  data  required  for  the  Financial 
Management  portion  of  the  IDA/FMS  system.  This  data  is  gathered  in 
the  Uniform  Automated  Data  Processing  System  (UADPS-SP)  which  is  a 
supply-oriented  system.  Daily  UADPS-SP  transactional  codes  are 
converted  to  IDA/FMS  execution  codes  on  a  tape.  This  tape  is  provided 
to  the  IDA/FMS  system  daily.  All  other  input  is  processed  via  CRT 
terminals. 

All  users  are  identified  by  a  password  which  permits  access  to 
specific  functions.  The  password  does  not  appear  on  the  screen,  but 
identifies  the  organization  attempting  to  input  to  the  system.  IDA/FMS 
has  a  menu  tailored  to  each  system  user.  There  are  57  applications 
available  in  the  IDA  menu  and  93  applications  available  in  the  FMS 
menu.  Only  those  applications  authorized  are  diplayed  to  an  individual 
operator  and  system  controllers  prohibit  the  accessing  of  users 
information  by  other  system  users.  A  more  detailed  discussion  of 
system  inquiry  capability  is  presented  in  a  subsequent  section  of  this 
system  description. 

The  system  is  normally  available  from  0700  to  1600  Monday  through 
Friday  for  user  inquiry  or  input.  Some  classi f ications  of  input  for 
the  IDA  module  require  batch  balancing  prior  to  system  processing. 
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Batches  which  fail  to  balance  are  printed  on  the  users  printer  and 

* 

are  corrected  by  the  user. 

4.  DATA  CONVERSION 

The  IDA/FMS  system  utilizes  CRTs  with  control  units  and  dedicated 
telecommunications  line.  The  system  has  been  designed  to  permit 
decentralized  input  stations  with  CRTs  and  has  a  centralized  key 
station  with  data  entry  devices  to  provide  back-up  input  capability 
to  the  system.  The  NARDAC,  NAS  Pensacola  card  readers  are  utilized  to 
read  the  job  control  cards  to  the  IBM  360/65  prior  to  processing  the 
IDA/FMS  programs.  Communications  terminals  utilized  in  the  system 
are : 

.  IBM  3270  Compatible  Terminals  (3  types) 

.  IBM  3740  or  CMC-7  Data  Entry  System  Terminal 
.  Mohawk  7500  Terminal 

.  IBM  2963  Terminal. 

Several  CRTs  are  linked  to  one  control  unit  at  remote  sites  and  the 
I3M  360/65  has  a  front  end  communication  controller  associated  with 
it.  Use  of  the  systems  back-up  disk  to  tape  system  is  discouraged 
unless  terminals  are  inoperative. 


5.  SYSTEM  INTERFACES 


NETFMS  (Naval  Education  and  Training  Financial  Management 
System)  was  designed  and  introduced  at  the  NAS  Pensacola  prior  to  IDA 
implementation.  It  processed  the  accounting  data  via  On-Line  Data. 
Entry  System.  Although  independently  designed  and  operational  prior 
to  the  IDA  effort,  this  NETFMS  performed  the  accounting  functions  which 
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are  part  of  the  IDA  design.  An  IDA  (or  disbursing  capability)  was 
added  and  it  occurs  first  in  the  procesing  cycle  and  the  FMS  module 
utilizes  files  updated  during  the  IDA  processing.  IDA/FMS  is  the 
resulting  system  and  appears  as  one  system  to  the  users  of  the  system. 
This  total  system  has  been  designated  as  the  IDA  System  to  be  adopted 
in  the  Navy  Financial  Community  by  the  Navy  Comptroller's  Office.  It 
will  be  exported  to  various  sites  in  the  near  future. 

In  addition  to  the  supply  input  obtained  from  UADPS-SP  previously 
described  (see  Section  3),  there  are  several  other  systems  which  supply 
input  to  IDA/FMS.  These  systems  are: 

.  Civilian  Payroll  System 

.  Military  Manhour  Accounting  System  (3M) 

.  Military  Labor  System. 

This  input  is  either  biweekly  or  monthly  and  provides  information  for 
accounting  reports  produced  by  IDA/FMS. 

6.  SYSTEM  EDITS 


The  purpose  of  this  section  is  to  identify  the  types  of  editing 
performed  by  the  IDA/FMS  system.  Prior  to  input  into  the  system  the 
payment  validation  section  computes  the  total  amount  of  payments  to 
be  processed  and  enters  this  total  into  the  system,  with  similar 
procedures  performed  for  obligation  data.  After  entering  the 
individual  amounts,  the  system  automatically  adds  the  individual  totals 
and  compares  it  to  the  preentered  batch  total.  Accepted  batches  are 
listed  on  the  Accepted  Batch  Report  and  forwarded  to  the  edit  process. 
Batches  which  fail  to  balance  or  have  an  unacceptable  business  date 
or  are  missing  the  AAA  record  are  placed  in  a  suspense  file  for 
corrective  action.  A  subsequent  section  of  this  system  description 
discusses  error  correction  procedures. 
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AIL  accepted  batches  are  validated  for  accuracy  by  the  system. 
Regardless  of  the  type  of  input,  each  data  element  is  validated  for 
completeness  of  data  fields,  classification  of  data  digits 
( alpha/ numeric/ alphanumeric )  and  the  accuracy  of  data  elements.  All 
transactions  which  pass  this  initial  validation  appear  on  the  valid 
detail  transaction  report  and  are  passed  on  for  additional  processing 
by  the  payment  certification,  disbursement  processing,  and  accounting 
routines.  Invalid  transactions  are  placed  in  the  suspense  file  for 
cor rect ion. 

7.  ERROR  CORRECTION 


Error  correction  procedures  refer  to  those  activities  performed 
in  reprocessing  rejected  transactions  data.  In  the  CNET  IDA/FMS  system 
there  are  3  sets  of  correction  procedures  based  on  the  input  source. 
Each  of  these  3  categories  is  discussed  below. 

.  3741  Input 

.  CRT  Input 

.  Tape  Input 

(1)  3741  Corrections 


The  IDA  system  has  been  designed  to  retain  all  batches  which 
are  out-of-balance,  are  missing  the  AAA  record  or  have  an  invalid 
business  data.  When  any  of  these  errors  occur  the  batch  number 
and  narrative  description  of  the  error  conditions  will  be  returned 
on  disk.  Errors  other  than  those  mentioned  above  will  have  the 
complete  batch  rejected  and  the  error  conditions  noted. 

Correction  inputs  to  correct  out-of-balance  conditions  prior 
to  daily  processing  must  contain  a  code  which  denotes  that 
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correction  is  being  made  to  a  batch  or  that  the  cornel ete  bate 
needs  to  be  replaced.  Alpha  characters  will  identity  specif t 


codes.  All  batches  will  be  rebalanced  after 


correction. 


(2 )  CRT  Input 

All  transactions  will  normally  be  inputted  via  CRTs.  The 
key  to  disk  procedure  described  later  in  this  section  is  provided 
only  as  a  description  of  system  designed  backup  capability  which 
exists.  All  transactions  input  v  ia  a  CRT  will  be  validated  when 
keyed  and  edits  applied  instantaneously.  These  errors  will  be 
highlighted  on  the  CRT  for  immediate  correction.  Any  cut  of 
balance  batches  will  be  printed  if  requested.  When  batch.es  are 
placed  m  the  suspense  file  via  the  CRT,  the  inquiry  key  for 
future  correction  will  be  the  serial  number  and  batch  number. 


The  serial  number  is  not  actual  placed 


.he  recoru,  out 


internally  generated  by  the  system  when  printing  the  suspense 
file  items. 

I  3 )  Tape  Input 

As  previously  mentioned,  tape  input  is  used  only  as  a  back¬ 
up  for  normal  input  processing  which  will  be  via  CRT.  AIL  batches 
which  are  out  of  balance,  have  a  bad  business  date,  or  have  no 
AAA  idem i f icat ion  are  considered  rejects.  All  out-of-ba  lance 
batches  will  be  printed  daily  and  placed  in  the  suspense  file. 
The  system  provides  capability  for  corrections  to  be  input  via 
CRT  or  3741  and  insures  that  the  batch  is  rebalanced..  If 
additional  corrections  are  still  needed  a  message  is  immediate  Is 
transmitted  to  the  input  source  for  satellite  activity  rejection: 
that  are  duplicate  batches,  have  a  bad  business  date  or  activity 
or  EC.  The  complete  batch  must  be  reinputted. 


8. 


DATA  BASE 


The  purpose  of  this  section  is  to  identify  the  data  base  files, 
communication  links  and  processing  cycles  the  IDA  system  utilizes. 
Disk  files  are  utilized  by  the  IDA  system  and  it  is  controlled  by  a 
data  base  management  system  compatible  with  the  NETFMS  system.  The 
files  maintained  by  the  IDA  system  are  identified  in  Exhibit  A-5.  The 
processing  advantages  inherent  in  the  IDA  data  base  system  include 
simultaneous  updating  of  all  files,  inquiry  capabilities  for  certain 
data  elements  and  relationship  validations  of  all  data.  The  data  files 
used  and  the  types  of  data  in  each  file  are  briefly  discussed  below. 

.  Input  Queue  Data  Base  File  (DIDT/DETS) 

The  Input  Queue  Detail  Master  file  provides  access  to  the 
Input  Queue  Detail  (DETS)  file  by  sorting  on  batch  control 
number.  The  Detail  file  contains  records  linked  to  the 
various  batch  masters.  All  out  of  balance  batches  and 
invalid  or  erroneous  detail  transactions  are  passed  to  the 
batch  control  master  and  detail  files  for  later  correction. 

•  Batch  Control  Master  File  (BCHM) 

This  file  provides  a  control  point  for  entry  into  the  Batch 
Control  file  by  Batch  Control  Xumber. 

Batch  Control  File 

The  batch  control  file  contains  both,  out-of-balance  batches 
and  invalid  and  erroneous  detail  •.  r  >.ut  ions.  Transactions 
will  appear  on  an  invalid  transact  i  :n  report  when  they  are 
placed  in  suspense  and  these  transact  tons  will  appear  on 
the  daily  average  report  until  cleared  from  suspense. 
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Auxiliary  Appropriation  Master  File  ( AADM) 

This  file  contains  all  valid  appropriations  against  which 
payments  can  be  made  other  than  the  NETFMS  valid 
appropriations . 

Disbursing  Officer  Accountability  File  (DOAM) 

By  utilizing  the  disbursing  officer's  symbol,  this  file 
maintains  each  D.O.'s  accountability.  Daily,  this  file  will 
use  the  checks  issued,  collections,  and  adjustments  to 
determine  the  current  accountability  as  well  as  the 
cumulative  for  the  month. 

Contractor's  Information/Status  File  (CISM) 

This  file  contains  the  contractor's  ID  number  and  name  and 
address.  The  status  flag  in  used  to  prohibit  payment 
processing  for  contractors  who  are  bankrupt  or  owe  the 
government  money.  This  file  is  also  used  to  provide  access 
to  the  outstanding  contract  status  file  by  contractor 
number. 

Outstanding  Contract  Status  File  (OCSV) 

This  file  is  used  to  maintain  a  complete  status  of  each 
active  contract  until  it  is  completely  liquidated.  Once 
liquidated  a  contract  status  report  will  be  produced  showing 
no  unliquidated  balance. 

Suspense  File  Details  (BCHV) 

This  file  contains  all  batches  which  are  out  of  balance  or 
contain  invalid  or  erroneous  data  transactions.  All  batches 
remain  in  this  file  until  corrective  action  is  initiated. 
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Purchase  Order/Delivery  Order  Master  (ORDM) 

This  file  contains  the  contract  or  purchase  order  numbers 
and  the  delivery  order  number  for  all  records  in  the 
Outstanding  Contract  Status  File. 

Various  Reference  Files 


In  addition  to  the  files  outlined  above,  the  IDA  data  base 
contains  several  reference  files,  including: 

Suspense  File  Master 
Check  Number  Master  File 
Check  Register  File 
Contract  Number  Master  File 
Contractor's  Invoice  Master  File 
Invoice  Control  Master  File 

Purchase  Order/Contract  Delivery  Order  Master  File 
Auxiliary  Appropriation  Data  File 
Authorization  Accounting  Activity  Master  File 

FMS  Data  Base  Files 


Ledger  Account  Number  File  ( ACTM ) 

This  file  contains  the  General  Ledger  Account  titles, 
contains  codes  which  indicate  whether  this  is  a  credit  or 
debit  account  and  if  this  is  a  summary  or  subsidary  account. 

Unit  Identification  Code  File  (ARUI) 

This  file  provides  the  capability  of  validating  job  order 
UIC's,  extracting  the  alignment  code  and  responsibility 
center  of  each  UIC  and  determining  if  this  UIC  is  a  Public 
Works  Department. 
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This  file  assures  that  only  valid  cost  accounts  are  set  up 
in  job  order  masters.  It  provides  a  means  of  validating  the 
cost  accounts  when  job  orders  are  established. 


Cost  Center  Master  File  (CCDM) 

The  CCDM  file  provides  all  entry  point  into  the  Job  Order 
summary  file  (JOSV)  and  the  Organizational  Summary  File 
(ORGV ) . 


Document  Number  Master  File/Outstanding  Transaction 
File/Expenditure  File  ( DOCM/OSDT/EXPD ) 

The  Document  Number  Master  provides  an  entry  point  into  the 
Outstanding  Transaction  File  and  Expenditure  File.  The 
Outstanding  Transaction  File  provides  activities  with  both 
detail  and  summary  information  by  document,  job  order  and 
fiscal  year.  It  is  updated  by  transactions  entering  the 
system.  The  expenditure  file  provides  the  capability  to 
research  expenditure  activity  for  the  last  6  months. 

On-Line  Update-Change  File  (FRMM/FORM) 

This  file  permits  on-line  changes/updates  to  the  Job  Order 
Master  file. 

Job-Order  Master  File  (JORM) 

This  file  allows  system  authorized  users  to  add,  change,  or 
delete  job  orders.  It  provides  its  capability  to  view  job 
orders  and  review  data  elements. 
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Provides  the  capability  to  view  amounts  recorded  by 
transaction  type  as  of  the  previous  business  date. 


.  General  Ledger  File  (LEGV ) 

This  file  contains  the  data  reqired  to  produce  trial  Balance 
Reports  and  linkage  to  major  claimant  master,  sub-claimant 
master  and  responsibility  center  master  files. 

.  Travel  Order  Master  File  (TORM) 

This  file  contains  the  status  of  outstanding  travel  orders 
by  name,  order  number,  and  amount.  Activities  can  research 
0/S  travel  orders. 

REFERENCE  FILES 


Cost  Account  Linkage  Master  File  ( CADM ) 

Budget  Class  Linkage  Master  File  (BCCM) 

Expense  Element  Master  File  (EEDM) 

Equipment  Code  Master  File  (EQDM) 

Functional  Linkage  Master  File  (FLDM) 

Master  Claimant  Master  File  (MCDM) 

Organization  Summary/Plans/Norms  File  (ORGV) 

Program  Element  Linkage  Master  File  (PEDM) 

Responsibility  Center  Master  File  (RCDM) 

Public  Works  File  (PWDV) 

Reimbursable  Work  Order  Master  File  (RWOM) 

Sub-Cost  Center  Master  File  (SCCM) 

Sub-Claimant  Master  File  (SCDM) 

Sub-Function  Linkage  Master  File  (SFDM) 

Data  Control  File  (SUCR)  Table  Master  Table  File  (TBLM/TBLV) 


Detail  Hold  File  (TKEY/DETH) 

Chargeable  VIC/FAN  #Linkage  Master  File  (VFDM) 

Address  File  { ADRU ) 

The  IDA/FMS  files  are  stored  on  direct  access  storage  devices 
and  various  files  are  on-line  during  batch  processing  and  when 
communication  terminals  are  operating.  Disbursing  and  Job  Order  files 
are  available  for  on-line  updating  and  accounting  related  files  are 
available  for  access?  these  accounting  files  are  batch  updated  each 
night.  All  reports  are  produced  on  magnetic  tape  and  additional  log 
tapes  are  utilized  for  back-up  and  recovery.  IDA/FMS  disk  files  are 
periodically  transferred  to  tape  for  back-up.  This  transfer  provides 
a  vehicle  for  reconstruction  in  the  event  of  disk  malfunction.  Restart 
capability  consists  of  a  transaction  tape  log  which  will  inform  the 
operator  of  the  last  check  point  restart  position  for  reprocessing 
transactions. 

The  IDA/FMS  system  runs  on  a  daily,  weekly,  biweekly,  monthly, 
quarterly,  annual,  and  as  required  output  cycle.  Since  the  daily  cycle 
is  representative  of  all  processing  cycles,  it  is  the  only  cycle  we 
will  describe  in  this  system  description.  The  IDA  module  of  the  IDA/FMS 
system  begins  by  validating  and  updating  the  various  control  records 
needed  for  system  processing.  Input  transactions  are  then  validated 
and  the  data  base  files  updated.  Transactions  are  generated  for  the 
FMS  module  and  the  FRS  interface  tape  is  formatted.  Report  data  is 
then  extracted  and  reports  are  produced.  The  reports  produced  are 
discussed  in  the  following  section  of  the  system  description. 

The  FMS  module  has  as  its  major  function,  the  processing  of 
accounting  data.  Input  is  validated  and  data  base  files  synthesized. 
Computations  are  performed  and  any  required  maintenance  is  executed. 
Output  is  then  formatted  for  report  preparation  and  reports  are 
produced. 


Exhibit  A-6  which  follows  this  page  represents  the 
telecommunications  network  utilized  by  the  IDA/FMS  system.  The  system 
presently  services  90  terminals  and  54  printers  located  throughout 
region  #7.  Region  #7  consists  of  Kentucky,  Tennessee,  Alabama, 
Mississippi,  and  the  Northwest  corner  of  Florida.  Parts  of  Texas 
including  the  Naval  Air  Stations  at  Beeville,  Corpus  Christi, 
Kingsville  and  Dallas  also  are  served  by  IDA/FMS.  The  mainframe  is 
currently  an  IBM  360/65  with  a  core  size  of  2M  bytes.  There  is  a 
conversion  planned  for  midsummer  1980  to  a  UNIVAC  1100  machine.  The 
telecommunications  system  is  controlled  by  a  COM  10/3650  front  end 
communications  device  and  has  multi-port  modems  where  multiple  CRT's 
are  present  at  remote  locations.  Dedicated  lines  are  in  place  within 
the  Naval  Air  Station  at  Pensacola  and  phone  lines  are  utilized  for 
satellite  locations. 

9.  SYSTEM  REPORTING  AND  INQUIRY  CAPABILITIES 

The  purpose  of  this  section  is  to  identify  the  system  reports 
prepared  and  the  inquiry  capabilities  available  to  various  system 
users.  In  order  to  facilitate  our  discussion  in  this  regard,  we  have 
divided  the  discussion  between  system  reports  and  inquiry  capability. 
Each  is  discussed  below. 

System  reports  produced  by  the  IDA/FMS  system  can  be  classified 
as  daily,  weekly,  biweekly,  monthly,  quarterly,  and  annually. 
Additionally  there  are  "As  Required"  reports  as  well  as  terminal 
inquiry  capabilities  available  to  system  users.  The  system  produced 
reports  are  listed  by  module  in  Exhibit  A-7.  This  Exhibit  also 
identifies  the  report  frequency  for  all  system  hard  copy  products. 
Reports  we  reviewed  appeared  well  organized  and  consisted  of  control, 
status,  accounting,  cost  and  management  reports,  which  were  summarized 
at  various  levels. 

System  inquiry  capability  is  available  daily  to  system  users 
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SYSTEM  REPORTS 
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IDA  OUTPUTS 


REPORT/LISTING  TITLE 

FREQUENCY 

D/W/M/A/O/Q/A 

OUTPUT 

MEDIUM 

Out  of  Balance  Report 

D 

Printer 

Accepted  Batch  Report 

D 

Printer 

Suspense  Listing 

D 

CRT 

Suspense  Correction  List 

D 

Printer 

Overaged  Suspense  List 

D 

Printer 

Reconciliation  Report 

D 

Printer 

IDA  Transaction  Report 

D 

Printer 

Cashbook  Trial  Balance 

D  or  A/0 

Printer  (to  D.O.) 

(NAVCOMPT  2199) 

Check  Issue  Listing 

D 

Printer/CRT 

Collection  Register 

D 

Printer  (to  D.O.) 

Recap  of  Block  Level  Totals 

M 

Printer  (to  D.O.) 

(SF  1179) 

Check  Register 

M 

Printer  (to  D.O.) 

Appropriation  Adjustment  Report 

M 

Printer  (to  D.O.) 

Schedule  of  Confirmed  Deposits 

M 

Printer  (to  D.O.) 

Auxiliary  Appropriation  Data  File 

A/0 

Printer/CRT 

Contractor's  Information  Status 

A/0 

Printer/CRT 

Report 

Routine  Transaction  Audit  Report 

D 

Printer/CRT 

Payment  Certification  Detail 

D 

Printer/CRT 

Report 

Payment  Certification  Deferred/ 

D 

Printer/CRT 

Exception  Report 

Lost  Discount  Report 

D 

Printer 

IDA  OUTPUTS  (Continued) 
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REPORT/LISTING  TITLE 

FREQUENCY 

D/W/M/A/O/Q/A 

OUTPUT 

MEDIUM 

Military  Services  Report 
(NAVCOMPT  2182  or 
(NAVCOMPT  7000/17) 

M 

Printer 

Operating  Budget/Expense  Report 
(NAVCOMPT  2168  or  7000/8) 

M 

Printer 

Performance  Statement 

(NAVCOMPT  2169  or  7000/9) 

M 

Printer 

Disbursement  Notification 

Report ;  Interim 

D 

Printer  (to  D.O.) 
(at  FIPC) 

Daily  Payment  Register 

D 

Printer/CRT 

Daily  Balance  Sheet 

D 

Printer/CRT 
(to  D.O.) 

Schedule  of  Cancelled  Checks 

D 

Printer/CRT 
(to  D.O.) 

Contract  Status  Report 

D 

Printer/CRT 

Travel  Processed  Report 

D 

Printer/CRT 
(to  D.O.) 

U.S.  Treasury  Checks  (output) 

D 

Check 

U.S.  Treasury  Checks  (advice  of 
payment  stubs) 

D 

Stub 

Accounts  Payable  Report 

M 

Printer  (  to  NAFC 
WASH) 

Contract  Advance 

Payments ;  Report  of 

<2 

Printer 

(to  NAVCOMPT) 

Progress  Payments  Status  Report 

Q 

Printer 

(to  NAVCOMPT) 

Balance  of  Payments;  Initial 

Q 

Printer 

(to  NFC  Cleve 
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IDA  OUTPUTS  (Continued) 


REPORT/LISTING  TITLE 

FREQUENCY 

D/W/M/A/O/Q/A 

OUTPUT 

MEDIUM 

Annual  Class  Object  Report 

A 

Printer 

(to  NAVCOMPT) 

Monthly  Procurement  Summary 
Actions  $10,000  or  less 
(NAVCOMPT  1057) 

of 

M 

Printer 

Purchase  Statistics  (NAVSUP 

80) 

M/ 

A/0 

Printer 

Spoiled  or  Voided  Checks;  Report  of 


M 


Printer 
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FMS  OUTPUTS 


REPORT/LISTING  TITLE 

FREQUENCY 

D/W/M/A/O/Q/A 

OUTPUT 

MEDIUM 

RMS  J.O.  Master  Change  Listing 

D 

Printer 

Reimbursable  W.O.  Update  Listing 

D 

Printer 

Travel  Order  Advance  Master 

Update  Listing 

D 

Printer 

Input  Batch  Balancing 

D 

Printer 

RMS  Input  Batch  Control  Report 

D 

Printer 

Invalid  Input /Erroneous  J.O. 

Report 

D 

Printer 

Corrected  J.O.  Report 

D 

Printer 

P.W.  Labor  Summary 

D 

Printer 

Week-to-date  Input  Control 

D 

Printer 

Generated  J.O.  Transaction  List 

D 

Printer 

Generated  J.O,  Master  List 

D 

Printer 

Daily  Transaction  Journal 

D 

Printer 

Outstanding  File  Balance  Sheet 

W 

Printer 

Weekly  Transaction  Journal 

W 

Printer 

Weekly  General  Ledger 

W 

Printer 

Weekly  Fund  Status  (Detail) 

W 

Printer 

Weekly  Fund  Status  (Summary) 

W 

Printer 

Reimbursable  W.O.  Report 

W 

Printer 

RMS  J.O.  Master  List 

W 

Printer 

Organizational  File  Li?',  ing 

W 

Printer 

EXHIBIT  A-7 

5  of  7 


FMS  OUTPUTS  (Continued) 


REPORT/LISTING  TITLE 

FREQUENCY 

D/W/M/A/O/Q/A 

OUTPUT 

MEDIUM 

Reimbursable  W.O.  Master  List 

W 

Printer 

Expenditure  Listing 

W 

Printer 

Expenditures  by  Bill  // 

NAVCOMPT  2974 

w 

Printer 

Expenditures  by  Issuing  Activities 

w 

Printer 

Invalid  Work  Center  Labor  Class 
Listing 

w 

Printer 

Valid/Invalid  Adjustment 

Transact  ion 

w 

Printer 

Erroneous  Canceled/Completed 

J.O.  Report 

w 

Printer 

Weekly  Fund  Status  Report 

w 

Printer 

Control  Maintenance  Tab  C 
by  Shop  Report 

w 

Printer 

Control  Maintenance  Tab  C 
by  Work  Center  Report 

w 

Printer 

Anticipated  Norms  Listing 

M 

Printer 

Annual  Plans  Listing 

M 

Printer 

J.O.  Status  Report 

M 

Printer 

Appropriate/Non-Appropriate  Fund 
Report 

M 

Printer 

P.W.  Utilities  Cost  Report 

M-19818  (NAVCOMPT  2127) 

M 

Printer 

J.O.  Expense  Report 

M 

Printer 

Flying  Hours  Cost  Report  (FHCR) 
(OPNAV  7310.2) 

M 

Printer 

Reconciliation  of  Plant  Account 

M 

Printer 

1 
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FMS  OUTPUTS  (Continuted) 


1 

REPORT/LISTING  TITLE 

FREQUENCY 

D/W/M/A/O/Q/A 

OUTPUT 

MEDIUM 

1 

Outstanding  Transactions 

Journal  by  Resp.  Center 

M 

Printer 

I 

Outstanding  Transactions 

Journal  by  Cost  Center 

M 

Printer 

1 

Outstanding  Credit  Balance 

Listing 

M 

Printer 

Travel  Advance  Transaction 

Listing 

M 

Printer 

Average  Outstanding  Travel 

Advances 

M 

Printer 

NAVCOMPT  2170  (Financial  Ledger 
Reports) 

M 

Printer 

NAVCOMPT  2025  (File  Audit  Report) 

M 

Printer 

NAVCOMPT  2030 

M 

Printer 

NAVCOMPT  2193  (Report  on  Reimbursable 
Orders) 

M 

Printer 

NAVCOMPT  2051  (Labor  Roll  or  Material 
Charges  and  Credits) 

M 

Printer 

NAVCOMPT  2074 

M 

Printer 

r 

Object  Class  Report 

M 

Printer 

NAVCOMPT  176  Report 

M 

Printer 

Bupers  7301-1  Fan  Report 

M 

Printer 

- 

Housing  Cost  Report 

M 

Printer 

I 

Detail  Expense  Report 
(NAVCOMPT  7000.8) 

M 

Printer 

] 

«*> 

PW  TAB-B  Control  Maintenance 

Report  by  Shop 

M 

Printer 

Monthly  Report  of  Civilian  Employment 
by  App’n  (NAVCOMPT  2270) 

M 

Printer 

1 


EXHIBIT  A-7 

7  of  7 


FMS  OUTPUTS  (Continued) 


REPORT/LISTING  TITLE 

FREQUENCY 

D/W/M/A/O/Q/A 

OUTPUT 

MEDIUM 

Militarv  Service  Report  (NAVCOMPT 
2182) 

M 

Printer 

PW  TAB-B  Control  Maintenance 

M 

Printer 

Quarterly  Utilities  Cost  Report 

Q 

Printer 

Average  0/S  Accounts  Payable 

Q 

Printer 

NAVCOMPT  2127  Utilities  Cost 

Report 

Q 

Printer 

PW  Transportation  Cost  Report 

Q 

Printer 

Semi-Annual  Expenditure  Report 

Semi-A 

Printer 

J.O.  Master  List 

A 

Printer 

Responsibility  Center  Listings 

A 

Printer 

Responsibility  Center  Report  Distri¬ 
bution  Listing 

A 

Printer 

Cost  Center  Listing 

A 

Printer 

Sub-Cost  Center  Listing 

A 

Printer 

Outstanding  Transaction 

File  to  J.O.  Master  Recon¬ 
ciliation 

A 

Printer 

Flying  Hours  Cost  Report  (FHCR) 

A/M 

Printer 

Reimbursable  UF  Order  Transfer 

Report 

A 

Printer 

Obl/Expend.  Closeout 

A 

Printer 

Allotment/OB  Report 

A 

Printer 

Bi-weekly  Labor  Report  (Detailed)  Bi-Weekly 

Bi-weekly  Labor  Report  (Summary)  Bi-weekly 
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TERMINAL  MENU 


IDA  MODULE  -  SELECTION  LIST 


APP  Contractor  Information  Status 

View  Contractor  Information  Status 

Change  Contractor  Information  Status 

Delete  Contractor  Information  Status 

APP  IDA  AAA  UIC  Report 

View  IIA  AAA  UIC  Report 

Delete  IIA  AAA  UIC  Record 

Add  IDA  Appropriation  Record 

View  IIA  Appropriation  Record 

Change  IDA  Appropriation  Record 

Delete  IDA  Appropriation  Report 

Add  Disbursing  Officer  Record 

Change  Disbursing  Officer  Record 

View  Disbursing  Officer  Record 

Delete  Disbursing  Officer  Record 

Add  Record  To  AADM  File 

View  Record  in  AADM  File 

Change  Record  In  AADM  File 

Delete  Record  From  AADM  File 

View  IDA  Table 

Add  Obligation  Batch 

Change  Obligation  Batch 

Delete  Obligation  Records 

Delete  Obligation  Batch 
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Add  Payment  Batch 

Change  Payment  Batch 

Delete  Payment  Records 

Delete  Payment  Batch 

Print  Suspense  Batches 

Contract  Status  By  Contract  Number 

Contract  Status  by  Contract  DEL/CRI 

Contract  Status  by  Contract  DEL/Live 

Contract  Status  By  Invoice  Number 

Contract  Status  By  Conte  Invoice  No. 

Contract  Status  by  Check  Number 

Invoice  Payment  Inquiry 

Invoice  Payment  Certification 

View  Check  Register  Records 

Check  Cancellation 

Update  Doam  Monthly  Amounts 

Contract  Status  Audit  Update 

Invoice  Payment  Certification  by  Batch 

View  Contract  Status  by  Contractor  Name 

Print  Chain  of  OCSV  Records 

Aux  Appropriation  Inquiry  by  AAA-UIC 

Delete  ORDM  Record 

Unliquidated  Obligation  by  Requisition  NR 

Add  Stock  Fund  OBL  Batch 

Change  Stock  Fund  OBL  Batch 

Delete  Stock  Fund  OBL  Transaction 

Delete  Stock  Fund  OBL  Batch 

View  Travel  Order  Record 

View  Blanket  Purchase  Order  Agreement 

Add  Blanket  Purchase  Order  Agreement 

Change  Blanket  Purchase  Order  Agreement 

Delete  Blanket  Purchase  Order  Agreement 

BGHM/BGHV  File  Maintenance 
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TERMINAL  MENU 


FMS  MODULE  -  SELECTION  LIST 


View  Outstanding  Document  Details 

View  Outstanding  Document  Summary 

View  Cade  Report 

Add  Cade  Record 

Delete  Cade  Record 

View  UIC  Record 

Add  UIC  Record 

Delete  UIC  Record 

Delete  Table  Premium  Pay  Rates 

View  Expenditure  Record 

View  Trial  Balance  Titles 

Add  Trial  Balance  Titles 

Change  Trial  Balance  Titles 

Delete  Trial  Balance  Titles 

View  Responsibility  Center  Records 

Add  Responsibility  Center  Records 

Change  Responsibility  Center  Records 

View  Cost  Center  Records 

Add  Cost  Center  Records 

Change  Cost  Center  Records 

View  Sue  Cost  Center  Records 

APP  Sue  Cost  Center  Records 

Change  Sub  Cost  Center  Records 

View  General  Ledger  by  Activity 

View  General  Ledger  by  Major  Claimant 
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View  General  Ledger  by  Sub  Claimant 

View/Print  GL  Account  Posting  Criteria 

Outstanding  Detail  File  Maintenance 

View  Financial  Reports  by  Activity 

View  Financial  Reports  by  Major  Claimant 

View  Financial  Reports  by  Sub  Claimant 

All  Travel  Order  Record 

View  Travel  Order  Report 

Change  Travel  Order  Record 

Delete  Travel  Order  Record 

Add  Job  Order  Master 

View  Job  Order  Master 

Change  Order  Master 

Delete  Job  Order  Master 

View  Job  Order  Status 

View  Oblig/Exp  by  Resp  Center 

View  Oblig/Exp  by  Cost  Center 

View  Oblig/Exp  by  Sub  Cost  Center 

View  Reimbursables  Job  Orders 

View  Job  Order  Totals  by  Responsibility  Center 

View  Job  Order  Totals  by  Cost  Center 

View  Job  Order  Totals  by  Sub  Cost  Center 

Job  Order  Inquiry  By  Data  Element 

Add  Activity  Address  Record 

View  Activity  Address  Record 

Change  Activity  Address  Record 

Delete  Activity  Address  Records 

Reimbursable  Job  Order  Inquiry 

View  Reimbursable  Work  Order  Master 

Change  Reimbursable  Work  Order  Master 

Broadcast- Individual  Station/DRA&USER) 

Broadcast  by  Application  (Password  Depenient) 

Map  Display  Utility  Program 

General  Ledger  Account  Inquiry  by  Subhead 


EXHIBIT  A-8 
Pag*  S  of  8 

General  Ledger  Account  Inquiry  by  Resp  Center 

Expenditure  File  Maintenance 

Print  NETFMS  Suspense  Batches 

Input  NETFMS  Labor  Batch 

Change  NETFMS  Labor  Batch 

Delete  NETFMS  Labor  Transactions 

Delete  NETFMS  Labor  Batch 

Fund  Status  Inquiry  by  Resp  Center 

Fund  Status  Inquiry  by  Cost  Center 

Add  Document  Transmittal  Batch 

Change  Document  Transmittal  Batch 

Delete  Document  Transmittal  Records 

Delete  Document  Transmittal  Batch 

Add  Batch  Activity  Table  Record 

View  Batch  Activity  Table  Record 

Delete  Batch  Activity  Table  Record 

Add  Table  Premium  Pay  Rates 

View  Table  Premium  Pay  Rates 

Change  Table  Premium  Pay  Rates 

Add  1080  Billing  Addresses 

Delete  Cost  Center  Records 

Delete  Sub  Cost  Center  Records 

Add  Labor  Adjustment  Batch 

Change  Labor  Adjustment  Batch 

Delete  Labor  Adjustment  Records 

Delete  Labor  Adjustment  Batch 

Add  Work  Unit  Batch  -  Change  Work  Unit  Batch 

Delete  Work  Unit  Records 

Delete  Work  Unit  Batch 

View  1080  Billing  Address 

Change  1080  Billing  Address 

Delete  1080  Billing  Address 

Change  Travel  Order  With  No  Job  Order 

Add  1080  Bill  RM  Series  Batch 
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Change  1030  Bill  RM  Series  Batch 
Delete  1080  Bill  RM  Series  Records 
Delete  1080  Bill  RM  Series  Batch 
Release  1080  Bills  by  Activity. 


during  normal  working  hours.  The  user  must  enter  his  password  upon 

signing  on  the  system  and  each  unique  password  identifies  the  user’s 

* 

responsibility  and  limits  his  inquiry  capability  to  those  files  related 
to  his  function.  Comprehensive  menus  allow  the  user  to  select  specific 
system  applications  but  only  those  applications  authorized  are 
presented  to  the  user  on  his  menu.  The  system  will  not  permit  users 
to  view  or  change  information  outside  his  responsibility  and  attempts 
to  enter  such  requests  or  actions  are  not  accepted  by  the  system.  The 
total  menus  available  for  the  IDA  and  FMS  portions  of  the  system  are 
presented  in  Exhibit  A-8.  Additionally  any  information  which  a  user 
may  view  he  may  print  on  the  printer  located  at  his  location. 


11. 


DATA  RECONCILIATION 


The  purpose  of  this  section  is  to  review  the  data  reconciliation 
activities  which  take  place  after  the  preparation  of  system  produced 
reports.  These  reconciliation  activities  are  important  in  maintaining 
a  valid  and  accurate  data  base.  In  the  IDA/FMS  System,  all  batch 
numbers  are  accounted  for  weekly.  Satellite  activities  must  account 
for  the  batches  they  have  used  and  the  NETFPIC  and  Accounting  Branches 
reconcile  batches  utilized. 

NETFIPC  has  devised  a  form  whereby  pre-established  checkpoints 
have  been  determined  and  are  validated  weekly.  Additionally,  this  form 
(See  Exhibit  A-9 )  requires  general  ledger  account  balances  to  be 
reviewed  in  a  comprehensive  manner.  This  type  of  reconciliation 
requires  the  accounting  technician  to  verify  the  accuracy  of  system 
produced  general  ledgers  for  various  responsibility  centers.  This 
Accounting  Data  Check  also  validates  the  reasonableness  of  expense 
accounts  and  the  accuracy  of  the  outstanding  file  and  the  balance  in 
the  weekly  funds  status  report.  Forms  similar  to  the  current  fiscal 
year  form  presented  in  Exhibit  A-9  are  utilized  to  validate  1st  and 
2nd  prior  years  data.  All  of  those  data  check  forms  require  the 
utilization  of  transaction  journals,  general  ledgers  and  unique  expense 
reports.  This  accounting  information  is  related  to  fund  status  and 
outstanding  obligation  data.  This  type  of  comprehensive  reconciliation 
adds  significance  to  the  integrity  of  the  system  produced  data  and 
adds  creditability  to  the  information  maintained  in  the  data  base. 
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accounting  data  check  for:-.  for  navcompt  2199 

Current  Fiscal  Year 

_ A/C _ R/C _ FY 

Check  Points: 

T03l  «  21 63-1  Col  11  3211  +  3212  =  CR  Bal  Accepted  Reimb  Orders  =  1310 

9961  =  2168-1  Col  3  9951  +  9952  =  DR  Bal  A/C  967  =  2141 

9991/9995  »  2182 _ 32e0, 9964 .9994  »  3  Dal _ 


Funds 

1031 0 

+ 

CY  Expenses 

5010D 

1810D 

+ 

5321 D 

+ 

Unobligated 

3211 C 

5324D 

4- 

321 2C 

m 

Undistributed 

1933D 

+ 

Obligated 

f  2 

m 

Check  Point 

*= 

Disbursements 

1060C 

+ 

Expenses 

5000D 

+ 

151 2D 

1933D 

+ 

Suspense 

191 OD 

Accrued  Exp 

3311 D 

m 

1960D 

1st  PY  UDO 

3232C 

+ 

Accts  Payable 

2000C 

+ 

5020D 

CY  Expense 

+ 

2100C 

+ 

9955C 

Exp  Authority 

m 

Check  Point 

* 

2nd  PY  UDO 

3232C 

+ 

Check  Point 

+ 

503DD 

CY  Exp 

+ 

Direct  UDOs 

3230C 

+ 

9956C 

Exp  Authority 

— 

Reimb  Income 

401 OC 

- 

Direct  Obi  is 

09980 

* 

MRP  -  UDOs 

3239C 

+ 

MRP  -  Exp 

5324  D 

+ 

Check  Point 

0949 

MRP  061 

s 

Undelivered 

3230C 

♦ 

Orders 

3232C 

+ 

Obligated 

* 

Unobligated 

0931 D 

+ 

Balance 

09320 

4 

Unobligated 
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ACCOUNTING  CAT  A  CHECK  FORM  FOR  KAVCCMPT  2199 
Current  Fiscal  Year 


Available 

99510 

- 

Balance  Direct 

9S64D 

- 

Expenses 

9952D 

Sal  Reirb  1st  PY 

9965C 

+ 

Budgeted 

9951 C 

+ 

Bal  Reiiri  2nd  PY 

9956C 

+ 

Expenses 

9962C _ 

+ 

Accrued  Expenses 

3311 D 

3 

9963C 

+ 

REIK3URS 

ABLE 

FUNDS 

LESS 

UNDELIVERED  ORDERS 

LESS  INCOME 

UNOBLIGATED 

BALANCE 

18110 

3232C 

401 1 C 

- 

1  SI  2D 

3234C 

4012C 

= 

181 3D 

3235C 

4013C 

= 

1814D 

3236C 

401 4C 

181 50 

3237C 

401 5C 

r 

181  ED 

3238C 

4016C 

— 

1810 

3232C 

4010 

- 

3212 

Collected 

10400 

+ 

Accounts 

11000 

+ 

Receivable 

12000 

+ 

Income 

401 OC 
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PASS  Phase  II  (SDS) 
SYSTEM  DESCRIPTION 


The  purpose  of  the  this  System  Description  is  to  present  the 
results  of  our  research  into  Pay/Per sonnel  Administrative  Support 
Phase  II  (Source  Data  System),  PASS  Phase  II  (SDS).  We  have  obtained 
our  information  on  the  system  from  reviews  of  documentation  and 
discussions  with  project  management  and  other  personnel  involved  with 
PASS  Phase  II  (SDS).  The  level  of  detail  provided  is  highest  for  the 
first  phase  of  the  automated  system  development  as  that  is  the  phase 
currently  under  development.  The  system,  including  PASS  Phase  III,  is 
scheduled  to  be  fully  operational  and  integrated  in  FY-85. 
Descriptions  of  the  phases  of  the  automated  system  development  and  of 
the  overall  PASS  project  are  contained  in  Section  1. 

To  facilitate  an  understanding  of  PASS  Phase  II  (SDS),  we  have 
divided  our  discussion  into  the  following  sections: 

.  Background  and  System  Overview 

.  System  Documentation 

.  Source  Documents  and  Input  Preparation 

.  Automated  System  Interfaces 

.  Data  Base 

.  System  Edits  and  Corrections 

Reconciliations 
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•  System  Reports,  Inquiry  Capabilities  and  other  Products 

A  discussion  of  each  of  these  subject  areas  follows.  An  acronym 
list  is  provided  at  the  end  of  the  System  Description. 

1.  BACKGROUND  AND  SYSTEM  OVERVIEW 

The  purpose  of  PASS  Phase  II  (SDS)  is  to  automate  the  overall 
Navy  military  personnel  and  pay  management  information  systems  in 
order  to  improve  the  quality  and  timeliness  of  information.  Another 
objective  is  to  improve  the  pay  and  personnel  service  which  Navy 
service  members  receive.  PASS  Phase  II  (SDS)  will  replace,  among  other 
things,  the  present  optical  character  recognition  system  used  for 
processing  personnel  and  pay  related  transactions  in  the  field  and 
for  processing  personnel  transactions  as  inputs  into  the  manpower  and 
personnel  management  information  system. 

PASS  Phase  II  (SDS)  will  provide  for  the  automated  collection  of 
military  personnel  and  pay  information  for  the  Navy's  projected  525,000 
military  personnel.  The  Navy  will  have  pay  and  personnel  offices,  PASS 
Offices,  located  worldwide  where  there  are  concentrations  of  Navy 
personnel.  These  25  major  offices  and  152  satellite  offices  will 
collect  data,  transmit  it  to  headquarters  data  bases  and  provide  pay, 
personnel  management  and  passenger  transportation  services  to  Navy 
military  personnel.  Specifically,  the  average  PASS  Office  serves  40 
commands  and  maintains  2900  individual  pay  and  personnel  records. 

.  PASS  Phase  II  (SDS)  is  the  automated  data  system  being 

developed  to  support  the  PASS  Offices  and  interface  with 
headquarters'  pay  and  personnel  management  information 
systems.  PASS  Phase  II  is  the  system  being  described  in 
this  System  Description.  See  Exhibit  B-l  for  an  overview 
of  PASS  Phase  II  (SDS). 
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The  other  phases  are: 


.  PASS  Phase  I  is  the  consolidation  and  combination  of  military 
personnel,  pay  and  passenger  transportation  offices,  which 
had  been  separate  offices,  into  a  network  of  PASS  Offices. 
All  consolidations  and  combinations  are  scheduled  for 
completion  by  the  end  of  19S0. 

•  PASS  Phase  III  is  the  integration  and  improvement  of  the 
pay,  personnel  and  passenger  transportation  management 
systems.  The  accomplishments  of  this  phase  will  evolve  from 
and  build  upon  lessons  learned  and  procedures  developed  in 
Phases  I  and  II. 

Hereinafter,  PASS  Phases  will  be  referred  to  by  Roman  numerals.  PASS 
Phase  II  (SDS)  itself  has  four  phases  in  its  development  which  are 
referred  to  by  Arabic  numerals  and  are  described  in  a  later  part  of 
this  section. 

The  combination  of  PASS  Phase  I,  the  combination  of  pay,  personnel 
and  passenger  transportation  functions,  with  PASS  Phase  II  (SDS),  the 
automation  of  the  information  system,  will  facilitate  the  reporting 
of  personnel  transactions  to  headquarters  and  updating  the 
headquarters'  data  bases  from  about  one  hundred  fifty  two  PASS  Offices 
located  in  the  continental  U.S.  (CONUS)  and  overseas.  Another  function 
of  PASS  Phase  II  (SDS)  is  to  provide  an  automated  source  of  information. 
PASS  Phase  II  (SDS)  will  also  accommodate  the  down  flow  of  information 
from  headquarters'  pay  and  personnel  data  bases  on  headquarters 
initiated  personnel  and  pay  transactions.  This  information  will  down 
flow,  that  is,  be  transmitted  from  headquarters  to  PASS  Offices,  become 
a  part  of  the  local  records  and  will  be  used  to  provide  personnel 
management  and  pay  support  at  the  local  level.  Additionally,  PASS 
Phase  II  (SDS)  will  accomodate  payroll  processing,  the  placing  and 
receiving  of  reservations  for  overseas  travel  and  will  also  facilitate 


the  retrieval  of  information  connected  with  passenger  transportation 
functions . 

The  concepts  of  the  processes  described  above  are  diagrammed  in 
the  flowchart  in  Exhibit  B-l.  This  exhibit  illustrates  the  initiating 
transactions  generated  at  the  activity  level.  The  data  from  source 
documents  reflecting  these  transactions  are  entered  into  a  CRT  terminal 
by  a  keyboard  operator  at  the  PASS  office.  Once  released  for 
transmission,  the  network  controllers  regulate  the  entry  of  data  into 
the  PASS  files  and  its  transmission  to  headquarters'  data  bases,  if 
required.  Feedback  on  the  data  entered  into  headquarters'  data  bases 
is  sent  to  the  local  computers  and  from  there  to  the  data  base.  Some 
transactions  may  be  such  that  only  local  information  is  needed  to 
answer  the  inquiry.  The  bottom  level  of  the  flowchart  depicts  the 
various  classes  of  products  available  from  the  system.  It  is  this 
process,  flowcharted  in  Exhibit  B-l,  which  is  described  in  detail  in 
this  System  Description. 

Additionally,  the  Navy  plans  to  equip  a  number  of  ships  with  the 
Shipboard  Non-tactical  ADP  Program  (SNAP  II)  equipment.  PASS  Phase 
II  ( SDS )  applications  will  be  adapted  for  SNAP  II.  Data  entry  into 
the  PASS  Phase  II  (SDS)  system  will  be  by  either  telephone,  radio,  mail 
or  by  the  hand  carrying  of  a  disc  to  a  PASS  Office  or  Processing  Center 
which  will  serve  as  a  link  in  the  transmission  of  shipboard  pay  and 
personnel  data  to  headquarters'  data  bases.  The  mobility  of  ships 
means  that  a  ship  will  use  the  nearest  or  most  convenient  PASS  Office 
or  Processing  Center.  The  ship  will  not  be  assigned  to  only  one  PASS 
Office  as  are  fixed  location  activities. 


At  this  point,  it  is  necessary  to  briefly  review  the  PASS 
related  missions  of  those  organizations  involved  with  PASS  so 
that  we  may  understand  the  reasons  for  the  flow  of  information 


through  the  automated  Source  Data  System.  A  diagram  of  the 
organization  and  its  associated  information  flow  is  provided  by 
Exhibit  B-2. 


Deputy  Chief  of  Navel  Operations  (Manpower,  Personnel  and 
Training)  (OP-01),  Washington,  D.C.  -  Responsible  for 
planning,  programming  and  budgeting  for  the  Navy's  military 
personnel  requirements.  The  PASS  Program  Manager,  located 
within  OP-01,  is  responsible  for  PASS  policy  implementation 
and  program  execution. 

Naval  Military  Personnel  Command,  Washington,  D.C.  -  A  field 
command  reporting  to  OP-01  and  responsible  for  obtaining 
military  personnel  and  for  their  distribution, 
administration,  career  motivation,  advancement,  retention, 
separation  and  retirement.  This  command  executes  the  PASS 
program. 

Comptroller  of  the  Navy,  Washington,  D.C.  -  Responsible  for 
Navy  financial  management. 

Navy  Finance  and  Accounting  Center,  Washington,  D.C.  - 
Accounts  for  Navy  funds  for  the  Comptroller  of  the  Navy. 

Navy  Finance  Center,  Cleveland,  Ohio  -  Manages  the  Navy's 
pay  system  including  the  Joint  Uniform  Military  Pay  System 
(JUMPS) . 

PASS  Offices  -  Reporting  to  an  Area  Coordinator  and  receiving 
technical  guidance  from  the  Naval  Military  Personnel  Command 
and  the  Navy  Finance  Center,  CRT  terminal  equipped  PASS 
offices  are  located  in  areas  where  there  is  a  concentration 
of  Naval  personnel  in  order  to  provide  pay,  personnel  and 
passenger  transportation  services  to  Navy  military 


EXHIBIT  B-2 


Personnel  and  Pay  information  Flow 


PERSONNEL 
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personnel.  PASS  offices  are  entitled  Personnel  Support 
Detachments  (PSDs)  and  two  or  more  PSDs  are  under  the  command 
of  an  area  Personnel  Support  Activity  (PSA)  which  is  under 
the  command  of  a  major  claimant  such  as  a  Fleet  Commander. 
Processing  Centers  (PCs),  which  contain  computers  and  other 
peripheral  equipment  are  either  part  of  the  PSA  or  located 
at  a  Navy  Regional  Data  Automation  Center  (NARDAC)  in  close 
proximity  to  the  PSA.  Current  plans  call  for  all  but  ten 
Processing  Centers  to  be  located  at  NARDACs. 

( 2 )  Headquarters'  Data  Bases 

PASS  Phase  II  (SDS)  will  interface  with  two  headquarters' 
data  bases.  The  Manpower,  Personnel  and  Training  Information 
System  (MAPTIS)  collects,  stores  and  reports  overall  Navy  manpower 
strength  and  personnel  information.  MAPTIS  is  managed  by  the 
Naval  Military  Personnel  Command  located  in  Washington,  D.C.  The 
second  system  is  the  Joint  Uniform  Military  Pay  System  (JUMPS) 
operating  at  the  Navy  Finance  Center,  Cleveland,  Ohio.  The  purpose 
of  JUMPS  is  to  use  ADP  to  assist  in  the  processing  of  payrolls 
and  to  use  accrual  accounting  and  automation  to  provide  a 
financial  reporting  system  for  the  Military  Personnel,  Navy 
appropriation.  Plans  are  to  collocate  MAPTIS  and  JUMPS  at  NFC 
Cleveland  in  1982. 

( 3  )  ADP  Architecture 

PASS  Phase  II  (SDS)  is  an  ADP  system  with  distributed  data 
processing  and  distributed  data  bases.  See  Exhibit  B-l  for  a 
conceptual  flowchart  of  PASS  Phase  II  (SDS)  and  Exhibit  B-3  for 
a  diagram  of  the  system  network.  PASS  Offices  will  have  CRT 
terminals,  such  as  the  Data  Speed  40/4,  and  printers  linked  to 
either  Interdata  7/32  Mini-Computers  or  UNIVAC  1100  computers 
and  associated  data  bases  with  CAL  COMP  1035/235-2  disc  drives. 
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These  computers,  called  field  host  processors  (FHPs),  will  be  at 
Processing  Centers  (PCs)  under  the  functional  control  of  the  PSAs. 
Most  processors  will  be  located  at  Navy  Regional  Data  Automation 
Centers  (NARDACs),  except  where  location  does  not  make  this 
feasible.  In  this  case,  the  processors  will  be  located  within  or 
close  to  the  PSA.  The  function  of  a  NARDAC  is  to  provide  data 
processing  services  for  all  Navy  activities  within  a  specified 
area.  The  terminals  to  be  purchased  will  not  have  processing  or 
storage  capabilities.  The  exact  equipment  for  PASS  Phase  II  SDS 
is  not  known  at  this  time.  It  will  be  purchased  as  a  result  of  a 
competitive  procurement.  The  equipment  discussed  in  this  System 
Description  is  the  equipment  used  for  purposes  of  the  cost/benefit 
study. 

The  FHPs  will  maintain  pay  and  personnel  data  bases,  process 
data  resulting  from  pay  and  personnel  transactions,  process 
payrolls  and  interface  with  JUMPS  and  MAPTIS.  Local  data  entry 
into  the  FHP  will  be  by  computer-assisted  conversational  mode  of 
operation  into  a  CRT  terminal.  Data  entry  procedures  at  the 
terminal  are  designed  to  allow  an  operator  with  virtually  no  ADP 
experience  to  operate  the  terminal.  Certain  batch  procedures, 
such  as  payroll  processing,  will  also  be  accomplished  by  the  FHP. 

PASS  Phase  II  (SDS)  requires  an  extensive  telecommunications 
network  capable  of  two-way  communictions  between  the  field  level 
pay  and  personnel  offices,  the  FHPs  and  the  central  sites  in  order 
to  relieve  the  reliance  upon  mail,  the  present  method  of  data 
transmission.  The  configuration  will  consist  of  dial¬ 
up/dedicated  communication  lines  between  the  PASS  Office  and  the 
FHP  and  between  the  FHP  and  the  Headquarters  Host  Processor  (HHP) 
at  the  central  sites  where  the  JUMPS  and  MAPTIS  data  bases  are 
located.  The  Department  of  Defense  Automatic  Digital  Network 
(AUTODIN  II)  is  envisioned  as  the  communications  link.  Various 
Data  Speed  40/4  terminal  controllers  will  be  utilized.  Field 
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files  will  be  updated  daily  with  both  local  and  central 
information.  Central  files  will  also  be  updated  with  information 
transmitted  daily  from  the  field. 

( 4 )  Functions 

PASS  Phase  II  (SDS)  is  being  designed  to  support  the 
following  functions.  Panel  numbers  listed  after  functional 
statements  indicate  the  panel  in  Exhibit  B-4  which  provides  a 
flowchart  to  support  gaining  an  understanding  of  the  functional 
statements  and  other  descriptions  contained  within  this  System 
Description. 

.  Strength  (Manpower)  Accounting  and  Reporting  -  Local 

activity  gains,  losses  and  other  changes  which  affect  Navy 
strength  to  MAPTIS  (Panel  1) 

.  Personnel  and  Pay  Data  Change  Reporting  -  Local  activity 
personnel  transactions  to  MAPTIS.  Those  which  affect  pay 
to  JUMPS  (Panel  2) 

.  Maintenance  of  Pay  Log  and  Payday  Processing  System  -  At 

PASS  Office,  maintain  individual  pay  and  personnel  history 
and,  at  the  Processing  Center,  automatically  compare  local 
pay  record  to  JUMPS  Leave  and  Earnings  Statements  prepared 
at  NFC,  Cleveland.  PASS  Offices  will  produce  payroll  checks 
or  electronic  fund  transfer  notices  (Panel  3).  This  is  a 
conceptual  description  of  the  payroll  function  which  has 
not  yet  been  definitized. 

.  Access  to  Personnel  Record  and  Pay  Record  -  At  PASS  Office 
by  terminal  (Panel  4) 

Disbursing  Officer  Summaries  -  Prepare  aggregations  of  pay 
information  for  reconciliation  anu  reporting  (Panel  5) 


Standard  Pre-defined  Reports  -  Provide  standard  personnel 
reports  for  local  activities  (See  Section  8  for  a  discussion 
of  produsts)  (Panel  6) 


.  Retired  Pay  Reporting  -  At  service  member's  retirement,  PASS 
Office  forwards  additional  data  required  for  processing 
retired  pay  to  NFC,  Cleveland  (Panel  7) 

.  Projected  Assignment  Notification  -  Notification  of  change 
of  duty  station  orders  from  NMPC  to  PASS  Office  (Panel  8) 

.  Transaction  Tracking  -  PASS  Phase  II(SDS)  monitors 
transactions  until  completed  (Panel  9) 

.  Ad  Hoc  Queries  -  Terminal  inquiries  at  the  PASS  Office  by 
individuals  or  by  local  commands  for  aggregated  information 
using  logical  relationships.  Hard  copy  reports  can  also  be 
provided.  Note:  This  capability  should  also  be  of 
assistance  to  an  auditor  (Panel  10) 

.  Transportation  Reservations  -  Request  and  receive  overseas 
transportation  reservations.  Store  and  provide  overseas  and 
CONUS  passenger  transportation  information  (Panel  11) 

.  Government  transportation  Request  (GTR)  Accounting  -  Monitor 
custody  or  issuance  of  GTRs  (Panel  11) 

Data  Base  Synchronization  -  Allows  for  the  reconciliation 
of  headquarters'  and  local  data  bases  to  one  another  (Panel 
12). 

(  5 )  PASS  Phase  II  (SDS)  Development  Phases 

In  order  to  build  the  above  functions  into  PASS  Phase  II 
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Functional  Flowcharts 


Functional  Flowcharts 


Functional  Flowcharts 
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Functional  Flowcharts 


(SDS),  a  four  phase  development  cycle  has  been  selected.  These 
phases  are: 


Phase  1  -  Prototype  development  and  implementation  at 
Personnel  Support  Branch  Office,  Crystal  City,  Arlington,  Va. 
scheduled  for  completion  by  March,  1981.  This  phase  will 
include  officer  and  enlisted  gain  and  loss  and  miscellaneous 
events.  After  evaluation  and  acceptance,  which  is  to  be 
completed  by  July,  1981,  the  prototype  will  be  installed  in 
other  selected  CONUS  sites.  This  system  is  currently  in 
this  phase  of  development. 

Phase  2  -  This  phase  will  add  personnel  reports  and  forms 
not  included  in  Phase  1,  ad  hoc  queries  and  standard  reports. 
Products  of  this  phase  will  be  tested  at  prototype  sites. 
On  completion  of  testing,  19  CONUS  PSAs  and  121  PSDs  will 
receive  the  capabilities.  User  testing  is  forecast  for 
completion  by  June,  1982. 

Phase  3  -  The  third  phase  will  add  payroll  processing 
capabilities.  After  prototype  site  testing,  CONUS  activities 
will  receive  the  package. 

Phase  4  -  This  phase  consists  of  the  addition  of  family 
separation  allowance  support  and  overseas  unique  functions, 
such  as  those  pay  allowances  which  personnel  stationed 
overseas  would  receive  and  those  processes  which  address 
dependents  located  overseas.  Testing  will  be  conducted  at 
a  prototype  site  and  then  implemented  within  CONUS.  The 
last  part  of  this  phase  will  be  to  install  the  complete  PASS 
Phase  II  (SDS)  at  planned  overseas  sites.  An  evaluation  of 
the  overall  PASS  effectiveness  is  projected  for  completion 
by  the  end  of  1985. 


3-10 


Subsequent  to  the  preparation  of  this  PASS  Phase  II  (SDS)  System 
Description,  certain  portions  of  the  plans  for  PASS  Phase  II  (SDS)  were 
changed.  The  purpose  of  this  section  is  to  outline  the  modified  plans. 
These  changes  were  made  in  order  to  export  PASS  Phase  II  (SDS)  to  the 
field  as  the  Navy  pay  and  personnel  system  one  year  earlier  and  to 
provide  increased  capabilities  in  the  field  at  an  earlier  time.  While 
these  changes  are  significant  in  terms  of  their  effect  on  the  PASS 
Project,  we  believe  they  are  adequately  outlined  herein  and  the  use  of 
this  section,  in  conjunction  with  the  remainder  of  this  System  Descrip¬ 
tion,  will  provide  the  reader  with  an  adequate  understanding  of  the 
PASS  Phase  II  (SDS)  system.  We  feel  the  changes,  as  outlined  below,  are 
basically  scheduling  changes  and  have  not  significantly  comprised  the 
integrity  of  this  system  description. 


The  essence  of  the  change  is  that  SDS  Phases  1  and  2  will  be 
combined  into  one  development  phase  called  Release  1.  Release  1  is 
scheduled  for  implementation  in  January,  1982.  At  that  time,  it  will 
be  mated  with  "Brand  Y"  mini-computers  and  a  prototype  test  conducted. 
Major  interim  products  are  scheduled  as  follows: 


System  Design  -  September,  80 
Programming  Completed  -  September,  81 


i  In  addition  to  those  pay  and  personnel  functions  planned  for  SDS  Release 
1,  Naval  Reserve  pay  and  personnel  functions  will  be  either  included  in 
\  Release  1  or  introduced  shortly  thereafter  as  Release  1A. 

{  SDS  Phase  3  (payroll  processing)  will  become  Release  2  and  its 

I 

implementation  rescheduled.  In  the  same  manner,  SDS  Phase  4  will 
become  Release  3. 
i  ■ 


i 
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2. 


SYSTEM  DOCUMENTATION 


The  purpose  of  this  section  is  to  discuss  the  documentation  which 
was  reviewed  in  order  to  obtain  information  for  this  system 
description.  A  preponderance  of  the  information  required  for  this 
system  description  was  obtained  from  documentation  as  there  was  no 
demonstration  site  available  for  observation. 

PASS  Phase  II  (SDS)  is  in  an  early  stage  of  development  and  the 
documents  provided  for  review  reflect  the  early  stage  of  development. 
The  functional  requirements  for  SDS  Phase  I  are  relatively  firm,  but 
new  requirements  and  changes  are  being  made  in  response  to  the  ongoing 
planning  and  design  process.  Additionally,  requirements  and  design 
specifications  from  NFC  Clevland  were  not  available  at  the  time  of 
this  review.  Information  on  SDS  Phases  subsequent  to  SDS  Phase  1  were 
less  detailed  than  the  information  for  SDS  Phase  1.  In  some  cases 
this  System  Description  can  address  only  the  concept  of  how  a  function 
in  a  subsequent  phase  will  be  performed  as  functional  requirements 
are  not  yet  available.  The  documentation  which  we  reviewed  was  written 
during  the  past  two  years  and,  like  most  ADP  system  developments, 
mirrors  the  changes  which  occurred  during  this  period.  We  have 
accomodated  this  change  process  by  giving  more  emphasis  to  the  later 
documents  and  by  having  a  working  draft  of  the  System  Description 
validated  by  members  of  the  PASS  Project  Office. 

The  following  documents  were  reviewed  in  order  to  obtain 
information  on  PASS  Phase  II  (SDS): 

.  Automated  Data  System  (ADS)  Development  Plan 

.  PASS  Management  Plan 

.  Prototype  Functional  Requirements 
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Standards  for  Program  Specif ications 


Officer  Loss  Event  Program  Specifications 


Gain  Package  Requirements 


Processing  Scenarios. 


Other  documentation  which  will  be  available  in  the  future  consists 


Functional  Descriptions 


Detailed  Requirements  Packages 


Subsystem  Specifications 


Program  Specifications 


Users  Manual 
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2.  orr-^CT  POCU*'~ATTP  a  Nr  I'TPUT  ?n.Fr'.?T5A?r” 


A  major  reason  for  developing  RASP  Phase  T I  (PPRl  is  to  provide 
to  headquarters  level  managers  accurat°  and  timely  information  on  pay 
and  personnel  transactions.  These  events  will  be  stored  in  local  data 
bases,  transmitted  to  the  headquarters’  data  bases  and  processed  within 
all  data  bases  so  that  pay  and  personnel  records  affected  can  reflect 
the  changes.  Source  documents  reflecting  pay  and  personnel  actions 
which  are  to  be  entered  into  PCS  will  be  precared  by  the  service 
member's  activity  or  the  P\f>?  Cffice.  A  representative  cf  the  command 
will  sign  the  document,  thereby  authorizing  it  for  entry  into  PASS 
Phase  IT  (SPS).  If  not  filled  cut  at  the  PASS  Cffice,  the  document 
will  be  forwarded  to  the  local  PASS  Cffice  for  processing.  Ccoies  of 
the  documents  were  not  available  at  the  time  this  System  Sescripticr. 
was  written.  The  source  documents  will  be  redesigned  from  the  present 
OCR  forms. 

The  prototype  system  under  development  for  SPS  Phase  1  is  beir.q 
designed  to  reflect  certain  personnel  transactions  which  will  be 
recorded  in  PASS  Phase  II  (STS).  The  transactions  are  discussed  in  a 
later  paragraph  of  this  section.  A  complete  list  of  events  which 
require  entry  into  CPS,  and  which  will  be  covered  by  applications  of 
subsequent  STS  phases,  is  not  available,  however,  tb  is  list  car.  be 
nrojected  from  an  inventory  of  forms  presently  used  for  pay,  personnel 
and  passenger  transportation  functions  matched  against  an 
understanding  of  the  objectives  and  functions  of  °ASS  Phase  II  (fnS). 
It  is  estimated  that  the  categories  of  transactions  listed  below  will 
be  used  to  generate  specific  events  for  entry  into  PRS. 


P*V 


Pay  and  allowance  transactions 
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.M  1  o  1 e  r  t  s 


-  ’’v/rr)  1  nrcce-ssinc 

Perscnno 1 


Chance  in  status 

Leave 


Disc  ini ine 

Deserve  personnel  matters 


education  and  training 


Pnssenaer  transportation 


Application  for  transportation 
Confirmations  of  transportation 

GTR  issuances 


Overseas  Passenger  reservations. 

A  definitive  review  of  system  input  events  is  possible,  v.  this 
tine,  or.lv  for  SCP  Phase  1  events  due  to  the  staqe  of  development  of 
PASS  Phase  II  ( S PS ) .  Turing  the  initial  prototype  phase,  officer  and 
enlisted  gain,  loss  end  mi  seel  1 aenous  events  are  being  developed.  ' 
main  event  is  an  event  in  which  there  is  a  receipt  cf  a  service  member 
at  an  activity  and/cr  a  main  in  the  number  of  norsornel  in  the  Davy, 
overall.  A  loss  event  is  one  in  which  there  is  a  less  of  a  service 
member  to  an  activity  and/cr  a  loss  to  the  Davy,  ".i  soel  1  arous  everts 


A 


3-14 


are  those  v/h  i  char.qe  .-lets  elcrents  of  a  service  rv”h°r'  s  perr^nr.'.  1 
rcrcrH.  The  ('ate  elererts  chanaeo  ore  net  those  which  wou  1  d  be  e’v-re 
os  ft  result  of  a  aain  cr  less  event,  T1  ■••'se  c.itoccries  cf  ever*  s  e  r»~ 
a  portion  of  all  the  transactions  which  °ARG  Those  IT  ( )  will 
eventually  process.  "here  are  *10  rain  events,  1°  less  everts  and 
miscel lnnecus  events  which  are  now  Paine  nrograr.ir ed.  Fxa.rr.ples  of  f'-r 
important  catenories  of  transactions  which  '-/ill  be  reported  are: 

.  Ga.  ir.  Events 


Activity  pains  cf  nersonne' 

'Tavy  personnel  strength  coins 

Temporary  Additional  Tutv  personnel  gains  or  returns 
therefrom 

Failure  of  personnel  to  report 

Corrections  of  data  errors  or  erroneously  submitted 
ga  ins 

Chanaes  in  status  from  enlisted  to  officer 


Loss  Events 


Activity  loss 

Release  from  active  duty 

Tenarture  on  Temporary  Additional  Tuty 

Absent  personnel 
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"’or  r^ct  ;cr.s  of  ’a*-  .*r  re  -f  rr  ^rr-r-ner  us  1  v  i t 

1-s  res 

.  <?c'?l  1  .■’nccus  Fvent  s 

Chances  in  the  data  strri  1 1  ed  cr  in  ir.d  i  "i  iual  sf  -  ~ 

social  security  number,  ethnic  lata,  cc!  1  a  ter  a  ?  ,;ut  y 
assionrrnts  and  occupational  ced 

Penort  of  preliminary  retirement  data 

-  Ch ano.?s  ir.  active  -’utv  chi  i .nation. 

To  obtain  an  idea  of  ccnposifion  cf  e-->  ch  cf  the  inn  i  v  i  d  u  a  1 

events,  th«  follcv/ir.n  details  from  the  Functional  roscrimficn  of  C,*l, 
Officer  Activity  Gain,  is  nrevide4  as  an  oxarrle, 

G.MM  F\’F‘F'_I  G01.  The  purpose  of  the  C/l  »v  ont  is  tc  report  an 
officer’s  iritial  arrival  at  his  permanent  duty  station  or 
temporary  duty  station.  ""'’is  event  is  not  used  h  o  report  -ar 
officer’s  arrival  at  a  temporary  additional  duty  ( v:ith  parser. al 
financial  record)  station.  The  C-01  transaction  results  in  the 
svstern-ger.eration  of  a  OP  Transaction  Code  tc  the  Caval  **i  1  itarv 
Personnel  Command  and  a  reporting  endorsement  to  orders  to  fh-3 
Navy  Finance  Center,  Cleveland. 

''hen  a  terminal  operator  in  a  PASO  office  receives  a  d  cement 
authorizing  a  transaction,  such  as  an  officer  gain,  the  terminal 
operator  can,  if  the  event  number  is  known,  call  up  the  appropriate 
screens  for  data  entry.  Fxhibit  B-5  diagrams  the  procedures  and  flow 
of  information  of  the  data  preparation  an  1  entry  process.  See  Fxh  ihit 
P-6  for  an  example  of  an  event  screen.  Tf  the  event  number  is  ncl 
known,  an  event  menu  can  be  used  to  obtain  the  proper  event  number. 

’  s  the  data  is  beino  entered,  if  belp  is  needed,  helm  screens  may  Vo 
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an  Event 


r«n  Ull*« 


It'.:  no.  Fxhibit 


if  ir  •■■’X'ri'lt'  of  i  '"e  1  ■ 


s  ■?rtrr''i;  on  i  screo",  it  is  1  to  '  nr..'.  crcff— :  :  i  t-d  '•"/  to 
metier  discusses  co.it  iro  .end;  veil  i.'.nticn.  "ter.  correct  icr. 


feeveree  nv 


i  it  inc  ire  vela  latior,  an  rvor.t  Centre  l  Vu~r* 


’ssione-i  ane  the  ternir.nl  operator  is  offeree,  the  cot  Let 


nsnittinc  or  cancel i no  the  transact ien. 


IS  C  UP.  1C 


'or  assianeii  to  the  trinsactior.  which  is  used  for  reforer.t 
'kino  ml  rcstirn  chances  to  the  or  ioin.nl  event  ir.cluiino 


henda carters  r  e  r  o  r  <  •  s . 


oners. ter  elec 


=ource  document 


ir.no  ta  ted 


•ar.s  n  i  t 


t  r •?.  r. s ci c  t  i  c r. ,  nr >' 


'scribed  in  Faction 
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Automated  Svstem  Interfaces 


\ 

The  purpose  of  this  section  is  to  describe  the  interfaces  between 
PASS  Phase  II  (SDS)  and  the  MAPTIS  and  JUMPS  Systems.  This  interface 
is  an  important  part  of  the  system.  It  is  through  the  interface  that 
the  Navy’s  Central  pay  and  personnal  accounting  systems  receive  data 
on  field  transactions.  This  interface  provides  for  the  timely  and 
efficient  collection  of  data  and  transmission  to  the  headquarters' 
data  bases  thereb  overcoming  the  significant  time  delays  in  receipt 
of  data  which  characterize  the  present  OCR  system.  There  is  also  a 
down  flow  of  data  from  the  MAPTIS  and  JUMPS  data  bases  to  the  PASS 
Phase  II  (SDS)  data  bases  maintained  at  the  Processing  Centers. 
Exhibits  II-l  and  II-5  depict  the  flows  of  data  between  the  various 
ADP  systems  involved.  The  processing  procedures  to  allow  for 
interfaces  are  described  in  section  5. 

( 1 )  Output  to  JUMPS  and  MAPTIS 

Each  transaction  which  is  entered  into  the  Source  Data  System 
has  a  routine  associated  with  it  which  is  programmed  to  determine 
which  external  data  bases  will  be  updated  with  the  newly  entered 
information.  For  example,  see  panels  1  and  2  of  Exhibit  B-4.  The 
routine  may  be  written  so  that  JUMPS,  MAPTIS,  both  or  neither 
receive  an  update.  Most  events  designed  during  SDS  Phase  1  are 
reported  to  at  least  one  headquarters  data  base.  The  example  of 
an  officer  gain  event  provided  in  Section  3  demonstrates  a 
transaction  which  would  be  reported  to  both  MAPTIS  and  JUMPS. 
Should  transmission  to  JUMPS  or  MAPTIS  be  required,  the 
transaction  will  be  converted  into  the  appropriate  output  format 
by  the  FHP. 


The  appropriate  format  is  the  same  as  that  by  which  the 


present  OCR  forms  provide  inputs  to  JUMPS  and  MAPTIS.  This  format 
is  designated  a  Transaction  Code  (TAC)  when  transmitted  to  the 
HHP.  (See  Section  3  for  the  use  of  a  Transaction  Code  in  the 
Officer  Gain  Event).  Automated  PASS  Phase  II  (SDS) 
telecommunications  system  network  controllers  will  execute  the 
transmission,  acknowledgement  and  any  required  retransmission  to 
PASS  and  JUMPS. 

The  method  of  input  to  JUMPS  and  MAPTIS  described  above, 
coupled  with  SDS  Phase  1  reported  events,  fulfills  the  following 
functional  requirements  : 

.  Strength  accounting  reporting  -  MAPTIS  files  will  be  updated 
as  to  the  numbers  of  NAVY  personnel,  numbers  in  each  rate, 
rank,  skill  speciality  and  on  board  count  in  relation  to 
requirements  (See  Panel  1  of  Exhibit  B-4 ) 

.  Personnel  data  change  reporting  -  Updates  MAPTIS  to  maintain 
the  master  personnel  file  of  each  service  member  (See  Panel 
2  of  Exhibit  B-4) 

.  Pay  data  change  reporting  -  Updates  to  JUMPS  of  individual 
transactions  affecting  pay  for  the  master  pay  record  of  each 
individual  (See  Panel  2  of  Exhibit  B-4) 

.  Retired  pay  reporting  -  Transmits  the  additional  personnel 

information  required  by  NFC,  Cleveland  to  process  an 
individual's  retired  pay  (See  Panel  7  of  Exhibit  B-4). 

(2)  Input  from  JUMPS  and  MAPTIS 


In  PASS  Phase  II  (SDS),  there  are  requirements  for  the  down 
flow  of  information  by  telecommunications  network  from  JUMPS  and 
MAPTIS  HHPs  to  PASS  Phase  II  (SDS)  FHPs  which  then  process  the 


information  into  the  local  PASS  data  bases.  See  Exhibit  B-l  for 
the  concept  of  down  flow  and  Panels  3  and  8  of  Exhibit  B-4  for 
functional  flowcharts. 

In  MAPTIS,  data  will  be  formatted  for  SDS  by  a  front-end 
processor,  an  Interdata  732.  Within  JUMPS,  the  conversion  will 
be  accomplished  by  the  central  computer  with  the  Interdata  732 
used  only  as  a  communications  switch.  Transactions  planned  for 
SDS  Phase  1  implementation  are  primarily  personnel  management 
oriented  with  pay  implications .  Therefore,  the  specific  down  flow 
transactions,  which  are  listed  in  the  following  paragraphs,  are 
all  originated  at  NMPC  and  flow  from  MAPTIS.  During  SDS  Phase 
3,  extensive  payroll  functions  will  be  added.  At  this  time,  NFC 
Cleveland  will  transmit  pay  data  on  the  PASS  Phase  II  (SDS) 
network.  The  individual  Leave  and  Earnings  Statement  will  be 
computed  at  NFC,  Cleveland,  using  both  headquarters  and  field 
provided  data.  After  computation,  the  LES  will  be  transmitted  to 
the  local  Processing  Centers  on  the  PASS  Phase  II  (SDS)  network. 
At  the  Processing  Center,  it  will  be  automatically  compared  to 
locally  prepared  pay  computations  and  differences  reconciled  by 
disbursing  personnel.  As  a  result  of  the  reconciliation  and  the 
payments  made,  feedback  will  be  given  to  JUMPS  at  NFC  Cleveland. 

The  SDS  Phase  1  transactions  originating  from  MAPTIS  are: 

.  Projected  activity  personnel  gains  and  losses  are  ordered 

by  NMPC.  Exhibit  B-4,  Panel  3  diagrams  the  transaction.  NMPC 
uses  an  ADP  orderwriting  process.  A  product  of  this 
orderwriting  process  will  be  the  transmission  of  the 
assignment  transaction  by  PASS  Phase  II  (SDS)  network  with 
a  skeleton  record  for  the  local  mini  master  file. 

.  File  updates  such  as  Projected  Rotation  Dates  and  Additional 
Qualification  Designators  (an  employment  qualification)  are 
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NMPC  originated  data  elements.  Changes  to  these  data 
elements  may  be  requested  by  correspondence  from  Navy 
activities.  ' 

.  Certain  data  elements,  resident  in  the  FHP,  such  as  social 
security  number  and  name,  cannot  be  updated  locally  until 
MAPTIS  records  are  updated.  These  data  elements  are  written 
by  the  FHP  to  the  suspense  files  at  the  same  time  they  are 
transmitted  to  MAPTIS.  When  the  feedback  transaction  message 
from  MAPTIS  indicates  updated  records,  an  update  of  local 
records  will  occur. 

.  Personnel  loss  due  to  orders  is  similar  to  projected 
personnel  gain  except  that  a  local  record  will  not  be 
written . 

.  Synchronization,  or  data  base  to  data  base  reconciliation, 
will  be  described  in  section  7. 

In  all  the  cases  described  above,  data  elements  from  JUMPS  and 
MAPTIS  will  replace  the  respective  data  contained  in  the  record. 

The  addition  of  the  passenger  transportation  function  will 
require  the  ability  to  transmit  overseas  transportation  requirements 
from  PASS  Offices  to  reservation  offices  and  confirmed  reservations 
back  to  the  local  PASS  Office. 

PASS  Phase  II  (SDS)  indirectly  receives  input  from  ADP  systems 
other  than  JUMPS  and  MAPTIS.  Any  of  the  data  which  is  required  for 
PASS  data  bases  would  have  to  be  processed  by  MAPTIS  and  transmitted 
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5 . 


The  purpose  of  this  section  is  to  discuss  the  files  which  are 
part  of  PASS  Phase  II  (SDS)  and  the  processing  of  data  to  and  from 
these  files.  In  order  to  accomplish  this  purpose,  Section  5  has  been 
divided  into  subsections: 

.  Files 

.  Update  Processing  Cycle 

.  Network 

.  Restart,  Recovery  and  Back-up  Capability 

(1 )  Files 


The  files  which  are  discussed  are  those  files  associated 
with  SDS  Phase  1.  Subsequent  phases  will  generate  the  requirement 
for  additional  files,  and  will  also  use  those  files  created  for 
SDS  Phase  1.  These  files  are  updated  on  a  real  time  basis  for 
those  data  elements  which  the  PASS  Office  controls.  For  those 
which  are  controlled  by  headquarters,  update  is  on  an  as 
accomplished  basis,  anywhere  from  daily  to  three  times  per  week. 
There  are  also  files  located  at  NMPC  and  NFC,  Cleveland.  These 
files  are  a  part  of  the  MAPTIS  and  JUMPS  systems  and  will, 
therefore,  not  be  discussed  in  this  System  Description. 

The  files  associated  with  SDS  Phase  1  and  located  at  -he 
Processing  Center,  are: 


Mini  Master  File 


This  file  will  contain  a  personnel  record  for  every  Navy 
person  whose  records  are  administered  by  the  PASS  Office 
and  for  those  personnel  who  are  ordered  to  report  to  the 
area.  These  records  are  the  heart  of  the  data  base  for  SDS 
Phase  1.  Within  this  file  are  several  categories  of  records. 

Projected  Gains  Skeleton  Records.  These  are  skeleton 
records  built  from  a  minimum  amount  of  information 
which  is  provided  to  the  PASS  office  by  down  flow  from 
NMPC  when  NMPC  orders  a  person  to  the  area. 

On  Board  Skeleton  Records.  These  records  are  created 
for  personnel  who  report  in  to  the  PASS  Office  and  for 
whom  Projected  Gain  Skeleton  Records  have  not  been 
created. 

Full  Mini  Master  Records.  After  a  gain  event  has  been 
transmitted  to  NMPC,  and  successfully  processed  through 
MAPTIS,  a  Full  Mini  Master  Record  is  built. 

Temporary  Additional  Duty  Records.  Records  created  for 
personnel  who  are  assigned  on  temporary  duty  in  the 
area . 

The  data  elements  contained  in  these  files  are  those  data 
elements  which  a  personnel  record  would  have,  e.g.,  name, 
social  security  number,  date  of  birth,  and  those  unique  to 
the  Navy  such  as  skill  qualifications  and  projected  month 
when  orders  should  be  received.  Other  examples  of  data 
elements  are  listed  in  Exhibit  B-8. 


This  file  is  used  to  record  all  events  forwarded  to 
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Data  Elements 


The  below  listed  data  elements  represent  a  partial  list  of  data 
elements  which  can  be  used  to  construct  a  pre-defined  report  or  an  ad 
hoc  query  for  general  information  about  a  Navy  activity 

.  Basic  Orders  Estimated  Date  of  Loss  -  Indicates  the 

prospective  date  of  loss  to  the  Navy  or  when  a  member  is 
available  for  transfer 

.  Authorized  Separate  Rations  -  Indicates  the  authorization 
to  receive  separate  ration  payments 

.  Date  of  Rank  -  Indicates  the  date  of  the  officer's  present 
rank 

.  Dependents  on  Station  Overseas 

.  Expiration  Date  of  Active  Obligated  Service 

•  Estimated  Date  of  Detachment  -  the  date  a  service  member 

will  be  detached  from  the  present  duty  station. 

.  Ethnic  Group 


Primary  Navy  Enlisted  Classification  Code  -  A  job 
qualification  listing. 


headquarters.  When  feedback  from  the  HHP  indicates  final 
disposition,  the  particular  record  will  be  deleted  from  the 
Suspense  File.  While  in  the  Suspense  File,  the  record  can 
be  obtained  by  interactive  query. 

Event  Register  File 

This  file  lists  all  events  transmitted  to  a  headquarters  by 
either  Event  Control  Number  or  Social  Security  Number.  Daily 
and  monthly  reports  of  its  records  will  be  printed.  The 
contents  of  the  file  may  be  deleted  on  a  monthly  basis  or 
retained  for  historical  purposes. 

Hold  File 

This  file  will  allow  the  PASS  Office  to  enter  and  store  an 
event  prior  to  its  effective  date,  without  transmitting  the 
event  to  a  headquarters.  While  in  this  file,  the  events  can 
be  retrieved,  corrected,  transmitted  or  deleted.  They  will 
not  be  machine  edited  until  approved  for  transmission. 

Pay  Input  Log 

All  pay  and  personnel  data  elements  which  are  required  for 
the  service  member's  pay  account  must  be  maintained  on  an 
automated  file  to  be  used  by  disbursing  personnel. 


UIC  File 

This  reference  file  is  used  to  verfiy  the  validity  of  Unit 
Identification  Codes  (UICs).  The  UIC  is  a  unique  numerical 
identifier  assigned  to  each  naval  activity.  One  of  the  data 
elements  for  the  events  programmed  in  SDS  Phase  1  is  a  UIC. 


Miscellaneous  Support  Files/Tables 


These  files  and  reference  tables  will  support  pay  and 
personnel  edits.  Examples  are: 

Transaction  Queue  File  -  When  a  transaction  contains 
the  same  data  elements  as  a  previous  transaction  which 
has  not  yet  been  accepted  by  JUMPS/MAPTIS,  the  second 
transaction  cannot  be  transmitted  until  the  first 
transaction  is  accepted.  In  this  case,  the  second 
transaction  is  written  to  the  transaction  queue  file. 

Pending  Validation  File.  When  released  from  the 
transaction  queue  file,  a  transaction  is  written  to  the 
Pending  Validation  File  for  batch  processing  through 
the  edit  parts  of  programs. 

Event  Error  File  -  This  FHP  file  contains  events  which 
have  errors  discovered  as  a  result  of  editing  which 
have  not  yet  been  corrected. 

Feedback  Impact  File  -  This  file  is  written  by  the  HHP 
and  transmitted  to  the  FHP.  It  contains  feedback  from 
the  HHP  and  non-SDS  data. 

.  TAD  Record 

This  file  will  maintain  records  for  activities  which  order 
or  receive  personnel  on  temporary  additional  duty. 

(2)  Processing  Cycles 


SDS  will  operate  on-line  between  PASS  Offices  and  Processing 
Centers  during  the  regularly  designated  work  day  at  which  time 


PASS  Offices  will  provide  pay,  personnel  and  passenger 
transportation  services  to  customers.  When  the  transaction  data 
has  been  entered  and  edited,  the  terminal  operator  can  elect  to 
transmit  the  data.  If  this  is  done,  the  data  is  released  to  the 
network  queue  for  batch  transmission  to  the  appropriate  HHP(s). 
Programs  within  the  FHP  determine  whether  MAPTIS,  JUMPS  or  both 
data  bases  will  be  updated  and  also  format  the  event  for 
transmission.  At  this  time,  those  data  elements  that  can  be 
changed  by  PASS  Office  data  entry  are  changed  while  those  that 
can  be  changed  only  with  HHP  concurrence  are  written  to  the 
Suspense  File.  If  the  event  contains  data  elements  that  are 
already  awaiting  HHP  feedback,  the  record  is  written  to  the 
Transaction  Queue  file.  Once  feedback  is  received  on  the  prior 
entry,  the  record  is  written  to  the  pending  validation  file, 
edited,  then  batched  for  transmission.  See  Exhibit  B-5  for  a 
diagram  of  the  flow  of  data. 

For  the  eight  hour  period  following  the  work  day,  files, 
which  contain  transactions,  will  be  transferred  from  FHPs  to  the 
appropriate  HHP.  During  this  period,  feedback  on  SDS  transactions 
and  data  from  non-SDS  sources  such  as  down  flow  transactions  will 
be  transferred  from  HHPs  to  the  appropriate  FHP.  The  following 
subsections  describe  the  subsequent  processing  of  data  within 
the  FHP  and  the  HHP. 

.  HHP  Processing 

The  data  transmitted  from  the  FHP  to  an  HHP  will  be  retained 
in  queue  until  a  MAPTIS  or  JUMPS  update  cycle  processes  it. 
The  cycle  of  processing  this  data  will  range  from  daily  to 
three  times  per  week  depending  on  processor  availability. 
The  information  generated  from  field  transactions  will  be 
processed  into  the  records  of  individuals  contained  within 
MAPTIS  and  JUMPS  and  will  also  be  processed  to  files  which 
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aggregate  data  tor  financial  and  manpower  accocntmq 
purposes.  During  RHP  update,  new  data  will  be  compared  to 
that  resident  m  the  data  base.  Based  on  the  logic  of  the 
application  program,  this  new  data  will  be  either  accepted 
or  rejected  and  the  status  of  the  transaction  data  processed 
into  an  Accepts  and  Rejects  File,  and  a  Feedback  Input  File. 
Tine  Feedback  Input  File  from  the  HHP  is  transmitted  to  the 
appropriate  FHP.  The  following  are  the  processing  actions 
the  HHP  can  take : 

Accepted, 
e laments 
updated . 


Transaction  -  All  FH?  transmitted  data 
are  accepted  and  the  JUMPS  MAPT IS  files  are 


Accepted  Transaction  with  Change  -  AIL  FHP  transmitted 
data  elements  are  accepted  and  the  JUMPS/ MAPTIS  files 
updated,  but  some  were  modified  by  headquarter's  data 
and  these  data  elements  will  be  changed  by  the  FHP 
processing  cycle  to  be  described  subsequently. 

Accepted  Transaction  -  Previous  Error  -  This  indicates 
corrected  data  from  a  prior  erroneous  FHP  submission 
and  updated  JUMPS/.MAPT IS  files.  The  corrected  data 
elements  will  be  changed  within  FHP  files. 

Rejected  -  Transactions  which  are  rejected  and  returned 
for  correction  at  the  Headquarters  level. 

Accepted  Transaction  -  Non-SDS  Origin-  This  transaction 
originates  from  Non-SDS  sources,  such  as  the  orders 
writing  process  which  is  a  down  flow  transaction,  and 
changes  data  elements  m  the  FHP  data  base. 


FHP  Batch  P recess ir.a 


FHP  batch  processing  serves  two  purposes: 


Processing  of  feedback  from  HHPs  for  FHP  file  update 
Production  of  standard  and  system  reports. 

FHP  batch  processing  will  occur  daily  between  midnight  and 
the  beginning  of  the  customer  service  period.  The  Feedback  Input 
File  is  read  and  those  data  elements  for  which  the  feedback  input 
file  indicates  HHP  acceptance  and  which  are  headquarter's 
controlled  data  elements,  are  written  from  the  Suspense  File  to 
the  Mini  Master  file.  Also,  non-SPS  data  is  written  to  the  Mini 
Master  file. 

After  files  are  updated,  standard  and  system  reports  are 
produced.  Standard  reports  are  produced  by  selection  of  the 
report  through  the  on-line  report  option.  Frequency  of 
requirements  for  standard  reports  are  not  known  at  this  time. 
See  Section  8(2)  for  a  listing  of  SDS  Phase  1  standard  reports. 
System  reports  are  called  for  by  the  batch  update  program  on  a 
daily  as-required  basis  and  are  listed  in  Section  8(6). 

( 3 )  Network 

Telecommunications  will  be  used  to  provide  the  interactive 
data  entry  capability  between  PSD's  and  NARDACs  or  other 
Processing  Centers.  Data  exchange  between  Processing  Centers  and 
NMPC  and  NFC,  Cleveland  will  also  be  accomplished  by 
telecommunications  network  with  terminal  controllers  and 
communications  controllers.  The  system  functional  requirements 
call  for  an  alternate  telecommunications  path  as  a  back-up  for 
the  primary  path.  Either  two  dedicated  paths  or  a  secondary  dial¬ 
up  capability  to  meet  the  alternate  path  requirement  will  be 
acceptable . 


3-2  2 


( 4  )  Restart,  Recovery  and  3ack-up  Capabilities 

System  requirements  are  written  to  prevent  the  loss  of 
automated  data  support  to  PASS  Offices  and  to  minimize  the  loss 
of  data.  Specific  requirements  are: 

.  Restart 

During  a  gradual  shutdown,  the  system  must  stop 
accepting  external  input  while  continuing  to  run  active 
work.  Wien  the  system  is  restarted.,  all  remaining  work 
including  input  and  output  must  be  restarted. 

In  the  event  of  the  abnormal  job  termination  of  batch, 
processing,  there  will  be  checkpoints  from  which  the 
job  can  automatically  restart. 

In  the  event  of  lost  communications,  terminal  operators 
will  be  able  to  resume  processing  at  the  last  completed 
transmission  if  they  reaccess  the  system  within  a 
certain  time  limit. 

.  Recovery 

If  files  are  lost  or  damaged,  files  should  be 
reconstructed  from  the  most  current  backup  files 


Batch  processing  input/output  data  must  be  recoverable 

Input/output  errors  should  be  detected  automatically 
and  recovery,  such  as  trials  of  all  paths,  automat ica 1 1 v 
initiated.  Status  information  should  be  provided,  when 
unrecoverable  input.,  output  errors  are  detected.. 
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Each  Processing  Center  must  provide  continuous  support. 
A  single  loss  should  not  deprive  the  system  of 
processing  capability.  If  one  CPU  is  lost,  all  programs 
must  be  executable  without  recompilation 

Alternate  telecommunications  paths  must  be  provided 

Backup  should  be  provided  for  application  data.  Disc 
files  should  be  dumped  to  tape  daily  and  a  log  of 
changes  should  be  kept  for  recovery  purposes.  A  minimum 
of  father  and  grandfather  backup  files  should  be 
retained 

Messages  should  be  retained  even  though  the  host 
computer  is  not  operating.  Backup  copies  of  mesages 
should  be  established. 
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System  Edits  and  Corrections 


The  purpose  of  this  section  is  to  describe  procedures  for  editing 
input  data  and  for  the  correction  of  errors.  This  section  also 
discusses  the  reconciliation  which  will  occur  between  data  bases. 
Reference  to  Exhibit  B-5  will  assist  in  the  understanding  of  the 
discussion  on  edits  and  error  corrections. 

A  design  objective  of  PASS  Phase  II  (SDS)  is  to  write  data  entry 
programs  which  provide  for  error  detection  and  correction  at  the  source 
of  the  data  entry.  In  order  to  meet  this  objective,  validation  programs 
contained  within  the  application  routine  will  perform  syntax  and 
relationship  edits,  with  assistance  from  data  files  and  tables,  at  the 
time  data  is  being  entered  by  the  CRT  terminal  operator.  A  combination 
of  error  messages  and  HELP  screens  displayed  during  terminal  data 
entry  will  assist  the  terminal  operator  in  the  correction  of  errors. 
Each  event  package  has  its  own  edit  program  and  related  error  messages. 
If  the  terminal  operator  needs  further  assistance,  a  HELP  screen  can 
be  called  up.  The  HELP  screen  will  provide  the  terminal  operator 
assistance  in  entering  the  correct  data.  In  all  cases,  events  cannot 
be  transmitted  to  headquarters  data  bases  if  the  data  has  not  passed 
local  edit  procedures.  However,  in  the  cases  of  an  unprojected  gain, 
local  override  will  permit  data  transmission. 

Edits  performed  during  terminal  entry  are  both  single  field  and 
cross-field  edits.  Single  edits  are  edits  to  determine  the  correct 
entry  into  a  field.  Some  edits  are  performed  by  comparison  of  entered 
data  to  a  table  such  as  the  UIC  table.  Cross-field  edits  are  unique 
for  each  event  and  are  dependent  on  the  relationship  between  two 
fields.  Examples  of  each  type  of  edit  are: 

Single  field  edit 


Must  be  valid  date  data  (YYMMDD)  and  not  greater  than 
today's  date 


Must  be  a  valid  hour  in  correct  format 

Must  match  various  tables 

.  Cross-field  edit 

If  country  =  blank,  the  city,  state  and  zip  must  be 
present 

If  days  travel  time  authorized  is  numeric  and  other 
duty  =  17  days,  travel  time  authorized  must  =  01  through 
15 

Errors  which  are  detected  result  in  an  error  message  at  the  too 
of  the  screen  and  the  display  of  the  symbol  "ERR"  to  the  left  of 
the  incorrect  entry-  As  discussed,  at  this  point,  HELP  screens 
provide  assistance  to  the  operator  in  making  corrections  to  the 
data.  .Another  method  of  editing  is  to  display  each  completed 
screen  prior  to  transmission  in  order  to  provide  the  terminal 
operator  with  an  opportunity  to  review  the  data  prior  to 
transmission.  This  is  accomplished  at  the  time  that  the  operator 
is  provided  with  a  send/ cancel  option. 

At  the  beginning  of  data  entry,  the  operator  enters  the  event 
number  and  the  social  security  number  of  the  person  to  be  reported 
on.  If  there  is  no  matching  social  security  number  m  the  tiles, 
an  error  message  is  displayed  and  the  event  cannot  be  entered. 

Editing  is  also  accomplished  by  a  comparison  of  the  Record 
Status  Code  against  the  gain  or  loss  event  selection  at  the 
beginning  of  data  entry.  If  the  gain  or  loss  event  is 
inapnropr iate,  that  is,  it  does  not  meet  the  conditions  for  the 
duty  status  of  the  person  whose  record  is  being  changed  as 
reflected  by  the  Record  Status  Code,  an  error  message  is  displayed, 
and  the  event  cannot  be  processed. 


As  discussed  in  section  4,  the  receipt  of  transaction  data 
at  one  of  the  headquarters  subjects  the  data  contained  in  the 
event  to  edit  at  the  headquarters.  Feedback  on  the  results  of 
the  edit  is  provided  to  the  Processing  Center  and  the  PASS  Office. 
Incorrect  entries  detected  at  headquarters  are  corrected  at 
headquarters.  These  edits  and  those  described  for  the  local  PASS 
Office  are  accomplished  for  those  data  elements  which  can  be 
changed  by  the  editing  activity.  Certain  data  elements,  due  to 
their  nature,  are  locked  and  cannot  be  changed  by  the  PASS  Office; 
these  can  only  be  changed  by  headquarters.  In  accordance  with 
the  logic  of  the  data  processing  operations,  other  data  elements 
can  be  changed  by  the  PASS  Office.  As  for  edits  between 
headquarters,  in  the  case  of  a  difference,  the  requirements 
package  to  which  the  system  is  being  designed  will  state  which 
edit  has  priority. 

7.  Reconciliation 

Reconciliation  between  field  and  headquarters'  data  bases 
is  considered  necessary  to  meet  the  PASS  Phase  II  (SDS)  objective 
of  improving  the  quality  of  pay  and  personnel  data.  See  Exhibit 
B-4,  Panel  12  for  a  diagramatic  presentation  of  the  reconciliation 
procedure.  Reconciliation  procedures,  although  not  yet  finalized, 
will  have  the  following  characteristics: 

.  Ownership  of  data,  i.e.,  field  or  headquarters,  in  terms  of 
which  can  change  the  data  elements,  will  be  considered. 

.  Reconciliation  should  be  automatic  on  a  quarterly  basis. 

Also,  PASS  Offices  should  have  the  capability  of  initiating 
reconciliation  on  an  as  required  basis. 

.  Consideration  of  data  elements  in  process  should  be  allowed 

by  the  reconciliation  process. 
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FHPs  wil  receive  reconciliation  records  from  HHPs.  The  data 
elements  will  be  compared.  If  there  are  no  differences,  a 
report  stating  that  the  reconciliation  of  the  individual's 
record  was  satisfactory  and  the  date  of  reconciliation  will 
be  prepared.  If  there  are  errors,  they  will  be  flagged  for 
research  and  correction  by  PASS  Office  personel  using 
standard  data  entry  facilities. 

.  A  daily  report  is  provided  to  the  PASS  Office  on  the 
reconciliation  status  of  records. 

Reconciliation  of  JUMPS  files  at  NFC  Cleveland  to  local  pay  data 
will  also  be  accomplished  as  part  of  payday  processing  support. 
Monthly,  a  JUMPS  Leave  and  Earnings  Statement  will  be  prepared  by  NFC 
Cleveland  and  transmitted  to  the  FHP.  It  is  compared  to  locally 
maintained  pay  records  and  any  discrepancies  are  identified  for 
reconciliation  by  PASS  Office  disbursing  personnel. 

The  concept  of  reconciliation  is  also  served  by  the  time-sequence 
of  updating  local  files.  Data  entered  at  the  local  level  is  written 
to  the  suspense  file  until  validated  by  headquarters  and  feedback 
provided  after  which  the  data  is  entered  into  the  mini  master  file. 
This  serves  to  keep  both  data  bases  in  synchronization.  Ownership  of 
data  elements,  a  concept  closely  allied  to  the  time  sequenced  events 
of  updating  local  files,  helps  to  keep  data  bases  synchronized.  As 
described  in  section  4,  headquarters  owned  data  elements  cannot  be 
changed  by  PASS  Offices. 

Various  reports  on  reconciliation,  errors  and  feedback  are 
prepared  for  headquarters. 

The  vigorous  application  of  edits  and  data  base  reconciliations 
in  evidence  in  the  design  of  PASS  Phase  II  (SDS)  provides  adequate 
insurance  for  the  accuracy  of  data  within  and  among  data  bases. 


System  Reports,  Inquiry  Capabilities  and  other  Products 


The  purpose  of  this  section  is  to  describe  the  end  result  of  PASS 
Phase  II  (SDS).  This  section  is  divided  into  the  following  subsections 
which  are  the  categories  of  products  available  from  the  system. 

.  Input  to  Headquarters'  Systems 

.  Reports  to  Naval  Activities  Being  Serviced  by  the  Local  PASS 
Office 

.  Inquiries  Concerning  Individuals 

.  Down  Flow  Transactions 

.  System  Generated  Reports. 

( 1 )  Input  to  Headquarters'  Systems 

A  primary  reason  for  designing  PASS  Phase  II  (SDS)  is  to 
have  accurate  and  timely  information  resident  in  the  MAPTIS  and 
JUMPS  headquarters'  data  bases.  The  procedures  for  accomplishing 
this  event  reporting  have  been  discussed  in  prior  sections. 
Exhibit  B-8  provides  a  partial  listing  of  data  elements  which  are 
contained  in  data  bases.  The  information  contained  within  these 
data  elements  will  contribute  toward  the  effective  accounting 
for  the  Navy's  overall  personnel  strength  and  Military  Personnel, 
Navy. obi igations,  accruals,  expenditures  and  collections. 
Resident  in  these  headquarters's  data  bases  are  the  Navy's  master 
personnel  records  at  NMPC  and  master  pay  records  at  NFC,  Cleveland 
for  each  Navy  service  member.  See  Exhibit  B-4,  Panels  1  and  2. 
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( 2  )  Reports  to  Naval  Activities  Being  Serviced  by  the  Local  PASS 
Office 


PASS  Offices  will  have  the  capability  of  generating  reports 
for  local  activities  being  serviced.  See  Exhibit  B-4,  panel  6. 
These  reports  will  contain  data  elements  from  the  mini  master 
records  of  the  personnel  assigned  to  the  command.  Reports  can 
be  generated  on  a  periodic  basis  or  on  an  as  requested  basis. 
Reports  can  be  requested  by  using  a  menu  of  reports  available  or 
can  be  constructed  on-line  by  the  user  from  data  elements  such 
as  those  of  Exhibit  B-8  or  by  calling  for  specific  records.  The 
report  can  be  received  on-line  or  submitted  for  off-line 
production.  Paper  copies  of  on-line  reports  can  be  obtained. 
There  are  fifty  two  candidate  reports.  Standard  reports  that 
will  be  provided  by  SDS  Phase  1  are: 

Personnel  activity  locator  report  -  Report  of  personnel 
assigned  to  an  activity 

.  Personnel  projected  rotation  date  -  Lists  date  personnel 
can  be  expected  to  be  lost  to  the  command.  There  will  be 
one  report  for  officers  and  one  report  for  enlisted 
personne 1 . 

.  Advancement  eligibility  -  Reports  those  enlisted  personnel 
eligible  to  be  recommended  for  advancement 

.  Enlisted  active  duty  obligation  -  Reports  remaining  service 
time  of  enlisted  personnel 

.  Locator  report  -  A  listing  of  the  personnel  at  an  activity 

A  copy  of  the  officer  activity  locator  report  is  presented 
as  Exhibit  B-9. 
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EXHIBIT  B-9 
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( 3 )  Inquiries  Concerning  Individuals 

In  order  to  accomplish  pay  and  personnel  management,  and  in 
order  to  be  responsive  to  customer  service  requirements,  e.g.,  the 
registering  of  an  allotment  from  pay,  PASS  Office  personnel  have 
a  requirement  for  access  to  information  on  personnel.  The  most 
common  procedure  to  meet  the  requirement  will  be  to  request  the 
individual's  pay  or  personnel  record  which  will  be  displayed  on 
the  terminal.  Paper  copies  of  the  screen  display  can  be  obtained. 
See  Exhibit  B-4,  Panel  4. 

(4)  Down  Flow  Transactions 


As  discussed  in  section  4,  transactions  which  flow  from  the 
headquarters  through  headquarters  data  bases  to  PASS  Phase  II 
(SDS)  data  bases  are  a  product  of  the  overall  combined  Navy  ADP 
systems.  SDS  Phase  1  will  include  the  capability  to  transmit 
information  on  personnel  orders  written  by  NMPC  to  PASS  Offices 
and  local  commands.  The  capability  will  exist  to  notify  the 
gaining  and  losing  activities  and  up  to  three  intermediate 
temporary  duty  stations.  See  Exhibit  B-4,  Panel  3  for  an  example. 
Other  NMPC  originated  or  approved  changes,  such  as  changes  to  the 
projected  rotation  dates  of  service  members,  will  be  down  flow 
data . 


In  subsequent  SDS  phases,  down  flow  transactions  which  will 
be  programmed  include: 

.  The  computation  of  Leave  and  Earnings  Statements  by  NFC, 
Cleveland  and  the  transmission  of  them  to  PASS  Offices. 

.  The  transmission  of  changes  to  pay  tables,  UIC  files,  etc. 

(5)  Future  Products 
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A  review  of  the  system  documentation  indicates  that  two 
major  products  will  be  designed  into  PASS  Phase  II  (SDS).  These 
are  : 


Payroll  Processing  -  NFC,  Cleveland  will  transmit  individual 
Leave  and  Earnings  Statements  to  FHPs.  A  comparision  by  the 
FHP  will  be  made  to  determine  if  local  and  headquarter's  pay 
data  is  correct.  Differences  will  be  reconciled  by  local 
disbursing  personnel.  Checks  will  be  printed  by  the  FHP 
using  batch  processing  under  the  control  of  disbursing 
officers.  A  by-product  of  this  process  will  be  feedback  to 
NFC,  Cleveland  on  payments  to  individuals.  Normal  disbursing 
reports  will  be  written  for  disbursing  personnel.  Examples 
are  : 


..  Statement  of  Accountability  -  Summary  totals  of 
all  receipts  and  expenditures 

..  Check  Register  -  List,  by  date,  of  each  Treasury- 
check  issued 

..  Report  of  Spoiled  and  Voided  Checks. 

Exhibit  3-4,  Panel  3  provides  a  flowchart  of  this  operation. 

.  One  function  of  the  PASS  Office  is  to  transmit  overseas 

passenger  reservation  requests  to  the  appropriate  scheduling 
activity,  e.g.,  the  Military  Airlift  Command  or  a  commercial 
airline.  Upon  receipt  of  a  confirmed  reservation  by  the 
PASS  Office,  information  on  the  reservation  will  be  entered 
into  the  local  PASS  Phase  II  (SDS)  records  and  also 
transmitted  to  the  service  member.  A  Government 
Transportation  Request  ( GTR )  will  be  provided  the  service 
member  as  a  ticket  and  accounting  for  GTRs  will  be 
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accomplished  by  the  FHP.  A  report,  primarily  for  accounting 
purposes,  will  be  sent  to  NMPC.  Non-overseas  passenger 
reservations  will  be  entered  into  PASS  Phase  II  (SDS)  by 
other  then  automatic  means.  A  flowchart  of  the  application 
is  depicted  in  Exhibit  B-4,  Panel  11. 

6 )  System  Generated  Reports 

Certain  SDS  Phase  1  reports  will  be  generated  by  the 
system  in  response  to  certain  events  or  to  provide  processing 
status.  These  are: 

Expired  Projected  Release  Date  -  This  report  lists  personnel 
whose  date  of  release  from  the  Navy  lias  passed,  but  for  whom 
no  notice  of  release  was  received  by  the  system.  Generated 
from  the  Hold  File  and  the  TAD  file. 

Expired  Duty  Status  Expiration  Dates  -  Similar  to  Expired 
Projected  Release  Date,  except  this  is  for  expired  Temporary 
Additional  Duty  and  is  generated  from  the  TAD  Record. 

Overdue  Events  -  List  of  overdue  events  from  the  Suspense 
File.  There  is  also  a  similar  report  from  the  Hold  File  and 
the  TAD  File. 

Reconciliation  Status  Reports  -  Reports  listing  records 
successfully  reconciled,  date  of  reconciliation  and  records 
which  did  not  reconcile  and  for  which  further  investigation 
is  required.  A  daily  report  is  prepared  for  each  PASS  office. 

Event  Listing  -  A  daily  list  of  events  transacted  from  the 
Event  Register  File  by  Event  Control  Number. 

Expired  Projected  Gain  -  A  report  on  personnel  who  'nave  been 
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ordered  to  report  and  whose  reporting  date  has  passed.  Data 
is  taken  from  the  Projected  Gain  Skeleton  Records  of  the 
Mini-Master  File. 

Error  File  Listing  -  A  list  of  events  entered  by  the  terminal 
operator  which  have  uncorrected  errors. 

Prospective  Assignment  Notice  -  A  list  of  personnel  for  whom 
notification  of  orders  assigning  the  personnel  to  the 
serviced  activity  has  been  received. 

Feedback  Report  -  A  list  of  feedback  transactions  received 
from  MAPTIS  and/or  JUMPS. 

Officer  and  Enlisted  BUPERS  Report  1080-11-  A  listing  by 
activity  and  by  PSD  of  personnel  assigned. 

Retained  Pay  Transmission  Log  -  A  log  of  transmitted 
transactions  which  affect  pay. 
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LIST  OF  ACRONYMS 


ADS  PLAN 

AUTODIN  II 

CONUS 

CPU 

CRT 

ECN 

FHP 

GTR 

HHP 

HQ 

JUMPS 

LES 

MAPTIS 

NARDAC 


Automated  Data  System  Development  Plan 
Automatic  Digital  Network  II 
Continental  United  States 
Central  Processing  Unit 
Cathode  Ray  Tube 

Event  Control  Number 

Field  Host  Processor 
Government  Transportation  Request 
Headquarters  Host  Processor 
Headquarters 

Joint  Uniform  Military  Pay  System 
Leave  and  Earnings  Statement 

Manpower,  Personnel  and  Training  Information 
System 

Navy  Regional  Data  Automation  Center 


NFAC 


NFC 


MM  PC 


OP -01 


PASS 

PC 

PSA 

PSBO 

PSD 

SDS 

SMAP 

TAC 

TAD 

UIC 


Navy  Finance  and  Accounting  Center 

Navy  Finance  Cen.ter 

Naval  Military  Personnel  Command 

Deputy  Chief  of  Naval  Operations  (Manpower, 
Personnel  and  Training) 

Pay/ Personnel  Administrative  Support  System 

Processing  Center 

Personnel  Support  Activity 

Personnel  Support  Branch  Office 

Personnel  Support  Detachment 

Source  Data  System 

Shipboard  Non-Tactica!  ADP  Program 

Transaction  Code 

Tempo r a r y  Add  1 1 iona 1  Duty 

Unit  Identification  Code 
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APPENDIX  C 


SYSTEM  SURVEYS 


The  purpose  of  this  Appendix  is  to  summarize  information  on  the 
distributed  systems  identified  by  the  Naval  Data  Automation  Command 
for  possible  further  review  during  our  field  work.  The  Naval  Data 
Automation  Command  was  the  primary  source  of  the  information. 
Supplemental  information  was  obtained  from  functional  managers  when 
needed  to  complete  the  survey. 

1 .  System  Information  Obtained 


In  order  to  evaluate  the  distributed  systems  under  development 
within  the  Navy,  survey  information  was  obtained  on  each  system 
identified  as  a  distributed  system  by  the  Naval  Data  Automation 
Command.  Our  purpose  in  obtaining  this  information  was  to  select  for 
further  study  certain  systems  which  best  fit  our  project  objectives. 

Below  we  present  the  types  of  information  we  obtained  on  each 
system  and  a  brief  explanation  of  each  category. 

TYpE  OF  SYSTEM 

A  brief  description  of  the  principal  type  of  data  which  the 
system  processes,  e.g.,  financial,  logistical,  supply, 
informational,  etc.  The  type  of  data  processed  is  indicative 
of  the  level  of  internal  control  needed. 
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SYSTEM  PESCR 1  PT  ION  ANP  OOP  ECTTYES 


1'!iis  iMtiMi'ry  briefly  st  .nes  the  basic  purpose  of  the  system 
and  .iesoribes  the  system  and  its  distributed 
oha rac t  e r i s t i os . 

SYSTEM  STATUS 


This  item  indiant es  the  development  status  ot  the  system  i:i 
terms  of  life  ovole  nannuemont  stnaos  of  development .  A 
nrnphic  overview  of  the  development  status  of  the  systems 
reviewed,  is  prov  ided  by  Exhibit  0-1. 


PES ION  AGENCY 


Here  we  identify  t ho  .money  which  is  desianinu  the  system 
or  the  .money  performing  the  duties  of  a  functional  man.mer, 
that  is  mnn.mina  other  oiM.mi.mt  iom;  responsible  for  the 
system  des inn. 

USER  AGENCY 


which  will 
system  ur.d 

love  1 opraent . 

ECCATTCN  OE  PEMCNSTRAT I ON  SITE 


Hert'  we  id.ent  i  fy  the  auenov  or  the  naencies 
receive  the  products  of  tin'  data  process  i  no 


This  item  identifies  tin'  command  and.  physical  location  of 
’he  svstems  under  review. 
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\nv  p«*rt  inent  deciiment.it  ion  nvainlhlo  at  the  Naval  Pat. a 
Automation  Command  is  listed  und.er  this  caption. 
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Development  Status  of  Navy  Distributed  systems 
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NOTE:  SNAP  not  included  as  it  is  a  procurement  of  computers  which  will  emulate  the  computers  presently  in  place. 


Intearated  Disbursing  and  Accounting  (IDA) 


Type  of  Svstem:  Financial 


System  Description  and  Objectives: 

Reflect  accounting  status  of  financial  transactions  from 
commitment  to  disbursement  and  provide  financial  status  to 
headquarters.  Future  plans  include  a  disbursing  capability.  There 
are  two  actual  systems.  One  is  in  prototype  status  at  the  Navy  Regional 
Data  Automation  Center  (NARDAC ) ,  San  Diego  and  is  being  designed  to 
support  the  Navy  shore  establishment.  The  other.  Naval  Education  and 
^raining  Financial  Management  System  (NETFMS),  is  operational  at  the 
Chief  of  Naval  Education  and  Training  (CNET)  HQ,  but  has  not  yet  been 
converted  to  provide  support  to  the  fleet,  the  purpose  for  which  it 
is  intended.  The  systems  are  to  be  on-line  systems  with  remote  inquiry 
and  data  processing  and  report  generation  at  a  number  of  satellite 
locations.  Accounting  information  will  flow  upward  through  the  Navy's 
financial  management  structure 

System  Status: 

(1)  Shore :  Prototype  running.  Prototyping  scheduled  to  be 
completed  in  May,  1980. 

(2)  Fleet:  System  operational  for  Naval  education  and  training 
requirements,  but  has  not  yet  been  converted  to  meet  overall  Navy 
need  s . 

DESIGN  AGENCY 


(1)  Shore:  Fleet  Material  Support  Office  (FMSO),  Mechanicsburg, 


( 2  )  Fleet:  CNET,  Pensacola,  FL 


tJser  Agency:  Comptroller  of  the  Navy,  ATLANTIC  Fleet,  PACIFIC  Fleet, 
other  Major  Claimants. 

Location  Of  Demonstration  Site: 


(1)  Shore :  NARDAC,  San  Diego,  CA 

(2)  Fleet :  CNET,  Pensacola,  FL 

Documentation  Available 


Automated  data  systems  plans  (ADS  Plans),  system  design,  system 
specifications,  functional  specifications,  economic  analysis  and 
equipment  requirements. 
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Shipboard  Non-Tactical  ADP  Program  (SNAP) 

Type  of  System 

Dependent  on  individual  ship's  mission  and  requirements.  Will 
have  financial,  supply,  personnel,  maintenance  and  local  unique 
requirements . 

System  Description  and  Objectives 

This  system  replaces  the  present  shipboard  computer  system 
( AN/UYK  5  computer)  in  order  to  accomplish  the  functions  described 
above.  The  system  is  a  distributed  system  and  is  self-contained  on 
each  ship.  Each  system  has  several  mini-computers,  various  terminals, 
distributed  data  management  and  a  network  configuration.  The  system 
will  interface  with  the  Pay  and  Personnel  Administrative  Support  System 
Phase  II  (Source  Data  System)  (PASS  Phase  II  (SDS))  and  the  Naval 
Aviation  Logistics  Command  Management  Information  System  (NALC0MI3). 

System  Status 


First  hardware  acquisition  is  expected  in  FY  1982.  This  computer 
will  emulate  the  AN/UYK  5  presently  installed  on  board  various  Navy 
ships . 

Design  Agency 

Naval  Sea  Systems  Command  (NAVSEA),  Washington,  DC  and  FMSO, 
Mechanicsburg,  PA. 

User  Aaencv 

.  »  _  A. 
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Atlantic  Fleet  and  Pacific  Fleet 

Location  of  Demonstration  Site 

AN/UYK  5  presently  on  various  Navy  ships 
Documentation  available 

ADS  Plans,  various  procurement  documents. 


Personnel  and  pay  functions. 


Svstem  Description  and  Objectives 

PASS  reports  personnel  and  pay  transactions  for  t'avv  personnel. 
This  system  is  designed  to  replace  an  optical  character  recognition 
system  which  has  high  error  rates  and  has  experienced  long  delay 
times.  The  master  files  at  the  Navy  Military  Personnel  Command  and 
the  Navy  Finance  Center  will  be  updated  from  the  field  PASS  offices. 
An  update  of  master  files  at  Headquarters  will  be  provided  by  CRT 
terminal  data  entry.  The  system  is  being  designed  in  four  phases, 
each  of  which  includes  various  pay  and  personnel  functions.  PASS 
Phase  II  ( SDS)  interfaces  with  the  Joint  Uniform  Military  Pay  System 
(JUMPS)  and  the  Manpower,  Personnel  and  Training  Information  System 
(MAPTIS)  and,  possibly,  with  SNAP. 

Svstem  Status 

Concept  approval  (Milestone  I/ADP  Plan)  completed.  Statement 
of  functional  requirements  and  system  specifications  for  the  first  o 
four  phases  has  been  completed.  Detailed  design  has  begun. 

Design  Agency 

Chief  of  Naval  Operations  Staff  (QP-01),  Washington,  D.C. 


User  Acencv 


All  major  claimants. 


Location  of  Demonstration  Site 

Not  yet  installed  at  a  prototype 
Documentation  Available 

ADS  Plan,  functional  description, 


or  operational  location. 


system  specifications. 
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Engineering  Field  Division  Management  Infornatior.  System  (EFD/MIS) 


"vpe  of  Svsten 


Financial,  logistics 

System  Description  and  Objectives 

This  system  is  designed  to  provide  Military  Construction,  Navy 
appropriation  accounting,  construction  status  and  shore  facility 
olanning  support.  The  Naval  Construction  Battalion  Center  has  a 
mainframe  connected  to  19  non- inte 1 1 igent  terminals  at  Engineering 
Field  Divisions  (EFD)  and  the  Naval  Facilities  Engineering  Command 
(NAVFAC).  The  planned  system  is  designed  to  replace  the  present 
terminals  with  intelligent  terminals  which  have  the  capability  for 
source  data  automation,  data  storage  and  report  generation. 

System  Status 

Beginning  acquisition  procedures  for  terminals  and  beginning 
sytems  development.  Most  of  the  programming  will  be  accomplished  after 
terminals  are  obtained. 

tesian  Acencv 


NAVFAC,  Washington,  DC. 


Dser  Acencv 


EFDs,  NAVFAC 


Locat ion  of  Demonstration  Site 


Present  Non- inte  1 1 igent  terminal  system  -  Naval  Construction 
battalion  Center,  Port  Hueneme,  CA 

Documentation  Available 

Request  for  Proposal  with  system  specifications. 


public  Works  Center  Manaoenent  Infornation  System  (PU'C  MIS) 


vpe  or  Svsten 


Financial  ana  logistics  supply 


System  Pescriptior.  and  Objectives 


Th  i  s  system  is  to  proride  Navy  Industrial  Fund  accoun.t  in.  a 
billir.a,  prod 'action  control,  family  housing  man.aaement  and  mate 
inventory  for  Wavy  Public  Works  Centers.  Each  PWC  system  has 
modules.  Each  has  its  own  mini -computer.  Modules  do  not  "talk 
one  another  on-line,  but  discs  from  one  module  can  be  carried  to 
modules  to  nroride  data  bases. 


System  Status 

Approaching  milestone  II  (in  this  case  design  and  acauisi 
approval  There  is  a  test  machine  which,  is  running  a  part  of 
nodule.  After  milestone  II  approval,  fi\-e  suites  of  hardware  w 
acouired  for  a  one  year  test.  Expect,  system  to  be  operational 


Pest an  A a e nor 


NAVFAC,  Washinaton,  PC 


Pser  Aaencv 


Mary  Public  Works  Centers 
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System  Stock  Point  Logistics  Integrated  Communications  Environment 
(SPLICE) 


Type  of  System 

Supply/Logistics,  financial.  Includes  inventory,  transportation, 
warehousing,  material  management  and  household  goods. 

System  Description  and  Objectives 

This  system  is  designed  to  provide  the  communications  and 
networking  to  bring  together  the  various  systems  which  serve  the 
functions  listed  above  into  a  standard  teleprocessing  network.  SPLICE 
provides  standardization  to  the  teleprocessing  of  data  so  that  various 
systems,  in  different  stages  of  development,  will  be  able  to  interact. 
The  system  will  consist  of  mini-computers  in  a  cluster  around  a  main 
computer  to  handle  interactive  processing  and  to  process  data  at  20 
sites  including  Navy  Regional  Data  Automation  Centers  (NARDACs),  Naval 
Supply  Systems  Command  (NAVSUP)  and  supply  stock  points.  Mini¬ 
computers  will  provide  data  processing  instructions.  While  SPLICE  is 
being  developed,  an  interim  system  will  be  used. 

System  Status 

Approaching  Milestone  II.  Design  with  some  testing.  Testing  is 
being  accomplished  using  IDA. 

Design  Agency 


NAVSUP,  Washington,  DC;  FMSO,  Mechanic sburg,  PA 


Major  claimants,  NAVSUP,  Supply  stock  points. 


Location  of  Demonstration  Site 

Interim  system  being  tested  at  NARDAC,  San  Diego,  CA. 
Documentation  Available 

Various  presentation  materials  on  the  system  and  the  ADS  Plan. 


Naval  Aviation  Logistics  Command  Management  Information  System 


(NALCOMIS ) 

Type  of  system 

Logistics.  Supply  and  maintenance  with  some  personnel. 

System  Description  and  Objectives 

The  system  is  to  provide  an  MIS  for  the  Naval  aviation 
organization  to  include  material  management,  maintenance  management 
aircraft  inventory,  aircraft  readiness  and  configuration  management 
The  system  will  tie  together  91  Navy  and  Marine  Corps  Air  Stations, 
major  Navy  ships  with  aviation  units  aboard  and  Marine  Air  Groups. 

System  Status; 

Approaching  Milestone  I.  Design  Phase. 

Design  Agency 

Naval  Air  Systems  Command  (NAVAIR),  Washington,  DC 
User  Agency 

See  System  Description 
Location  of  Demonstration  Site 

None  at  this  time. 

Documentation  Avaialble 


Mission  Element  Needs  Statement  (MENS).  (Other  documentation  at 
NAVAIR). 


